One document matched: draft-shirasaki-nat444-isp-shared-addr-07.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.wilson-class-e SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wilson-class-e.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 SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.shirasaki-nat444.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-isp-shared-addr-07" ipr="pre5378Trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title abbrev="NAT444 addressing models">
NAT444 addressing models</title>
<author fullname="Jiro Yamaguchi" initials="J." surname="Yamaguchi">
<organization abbrev="IIJ">Internet Initiative Japan Inc.</organization>
<address>
<postal>
<street>Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho, Chiyoda-ku</street>
<city>Tokyo</city>
<code>101-0051</code>
<country>Japan</country>
</postal>
<phone>+81 3 5205 6500</phone>
<email>jiro-y@iij.ad.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="Shin Miyakawa" initials="S." surname="Miyakawa">
<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>miyakawa@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="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="January" year="2012" />
<!-- Meta-data Declarations -->
<area>Transport</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>NAT444,ISP,Shared,Address</keyword>
<abstract>
<t>This document describes addressing models of NAT444.
There are some addressing models of NAT444. The addressing models have some issues of network behaviors, operations, and addressing.
This document helps network architects to use NAT444 after IPv4 address exhaustion.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="I-D.shirasaki-nat444">NAT444</xref> is one of solutions after IPv4 address exhaustion. ISP can select some addressing models of NAT444. The addressing models have some issues of network behaviors, operations, and addressing. This document describes these issues and solutions. It boosts up to deploy the IPv6 Internet.</t>
</section>
<section title="Addressing Models">
<t>
The key of addressing model is the address block between Customer Premises Equipment (CPE) and <xref target="I-D.ietf-behave-lsn-requirements">Carrier Grade NAT (CGN) </xref>. It's mentioned in this section. The best addressing model is "ISP Shared Address" which is defined in <xref target="I-D.shirasaki-isp-shared-addr" /> and briefly described in this section.
</t>
<section title="Global Address">
<t>ISP cannot assign IPv4 Global Address any more after the exhaustion.</t>
</section>
<section title="Private Address">
<t>It has two major problems.</t>
<section title="Policy Based Routing Issue">
<t>If both source and destination address of the packet are inside CGN, it has to go through CGN. The reason is that some servers reject receiving packets when the source address of receiving packet is Private Address. Therefore packets have to go through the CGN for rewriting the source address from Private Address to Global Address. Additionally, if Private Address and Global Address co-exist inside CGN, the ISP has to use Policy Based Routing (PBR).
</t>
</section>
<section title="Address Block Duplication Issue">
<t>
The Private Address in ISP's network could conflict with its customer's network address. Many CPEs between customer's network and ISP's network cannot route the packet under this situation. To avoid this, ISP has to negotiate with its all customers not to use the reserved Private Address block.
</t>
</section>
<section title="Class-E Address (240/4)">
<t>
It is known that some equipment such as routers and servers reject packets from or to this address block. So, to use this address block in ISP's network, ISP has to request its customers to replace their equipment. In addition to that, ISP might have to replace their equipment when it doesn't handle Class-E address packets properly.
</t>
</section>
<section title="ISP Shared Address">
<t>
ISP Shared Address is the newly defined IPv4 address block that is to be allocated from IANA free pool. It doesn't have any problem. Spending some blocks from the exhausting IANA free pool could be regarded as a problem, but from long view, this problem is much smaller than its great merit. ISP Shared Address is defined in <xref target="I-D.shirasaki-isp-shared-addr" />.
</t>
</section>
</section>
</section>
<section title="Example Architectures">
<t>
This section explains example architectures how to design NAT444 with ISP Shared Address.
</t>
<section title="Direct Routing inside CGN">
<t>
This architecture enables direct communication between customers inside same CGN. It has the following advantages.
<list style='symbols'>
<t>The packets don't go through CGN. (No hairpining)</t>
<t>The customers inside CGN can use bidirectional applications (e.g. TV Conference, VPN).</t>
<t>No need to use Policy Based Routing.</t>
</list>
</t>
<figure><artwork><![CDATA[
(The IPv4 Internet)
| Global Address
+----+----+
| CGN |
+----+----+
|
ISP Shared +-----------+----------+ ISP Shared
Address | .......... | Address
+----+----+ : : +----+----+
| CPE NAT | : : | CPE NAT |
+----+----+ : : +----+----+
Private | : : | Private
Address | v v | Address
+----+----+ +----+----+
|IPv4 Host| |IPv4 Host|
+---------+ +---------+
]]></artwork></figure>
</section>
<section title="CGN Bypassing">
<t>
This architecture is bypassing the NAT function of CGN. It has the following advantage.
<list style='symbols'>
<t>The customers inside an ISP can use bidirectional applications (e.g. TV Conference, VPN).</t>
<t>Any communication in single ISP doesn't consume CGN external port.</t>
<t>ISP's servers outside CGN can access CPE. (e.g. ICMP echo, SNMP, remote access)</t>
<t>ISP's servers outside CGN can distinguish which customer's connection it receives. (e.g. DNS, Mail)</t>
</list>
</t>
<figure><artwork><![CDATA[
(The IPv4 Internet)
|
| +--------+ Network Monitor
| | Server | (ICMP echo, SNMP)
| +----+---+ DNS, Mail, Web, etc
Global | | ^
Address +----------------------+ :
| ....................
| . : |
+----+----+ : : +----+----+ bypass NAT:
| CGN | : bypass : | CGN | Dst=ISP's Global Address
+----+----+ : NAT : +----+----+ or ISP Shared Address
ISP Shared | : : |
Address | : : | ISP Shared Address
+----+----+ : : +----+----+
| CPE NAT | : : | CPE NAT |
+----+----+ : : +----+----+
Private | : : | Private
Address | v v | Address
+----+----+ +----+----+
|IPv4 Host| |IPv4 Host|
+---------+ +---------+
]]></artwork></figure>
</section>
<section title="Global Address Customers inside CGN">
<t>
This architecture enables co-existing Global Address and ISP Shared Address inside CGN.</t>
<t>
It enables direct communications from ISP Shared Address customer to Global Address customer inside same CGN. It has the following advantage.
<list style="symbols">
<t>The ISP can put ISP Shared Address customer and Global Address customer in the same concentrator.</t>
<t>The customers inside CGN can use bidirectional applications (e.g. TV Conference, VPN).</t>
<t>No need to use Policy Based Routing.</t>
</list>
</t>
<figure><artwork><![CDATA[
(The IPv4 Internet)
|
| Global Address
+----+----+
| CGN | bypass NAT: Src/Dst=Global Address
+----+----+
| Global Address and ISP Shared Address co-existing
+----------------------+
| ......... |
+----+----+ : : +----+----+
| Firewall| : : | CPE NAT |
+----+----+ : : +----+----+
Global | : : | Private
Address | v : | Address
+-----+-----+ +----+----+
|IPv4 Server| |IPv4 Host|
+-----------+ +---------+
]]></artwork></figure>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks for the input and review by 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>IANA is to allocate a certain size of address block from IANA free pool.
The size of it is described
in <xref target="I-D.shirasaki-isp-shared-addr" /></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
There are no security considerations.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&I-D.shirasaki-isp-shared-addr;
&I-D.ietf-behave-lsn-requirements;
&I-D.shirasaki-nat444;
</references>
<!-- 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-24 05:08:08 |