Internet Engineering Task Force J. Yamaguchi
Internet-Draft IIJ
Intended status: Informational Y. Shirasaki
Expires: January 12, 2012 S. Miyakawa
NTT Communications
A. Nakagawa
Japan Internet Exchange (JPIX)
H. Ashida
iTSCOM
July 11, 2011
NAT444 addressing models
draft-shirasaki-nat444-isp-shared-addr-06
Abstract
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.
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 12, 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
publication of this document. Please review these documents
Yamaguchi, et al. Expires January 12, 2012 [Page 1]
Internet-Draft NAT444 addressing models July 2011
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. Addressing Models . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Global Address . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Private Address . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1. Policy Based Routing Issue . . . . . . . . . . . . . . 3
2.2.2. Address Block Duplication Issue . . . . . . . . . . . . 3
2.2.3. Class-E Address (240/4) . . . . . . . . . . . . . . . . 3
2.2.4. ISP Shared Address . . . . . . . . . . . . . . . . . . 4
3. Example Architectures . . . . . . . . . . . . . . . . . . . . . 4
3.1. Direct Routing inside CGN . . . . . . . . . . . . . . . . . 4
3.2. CGN Bypassing . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Global Address Customers inside CGN . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Yamaguchi, et al. Expires January 12, 2012 [Page 2]
Internet-Draft NAT444 addressing models July 2011
1. Introduction
NAT444 [I-D.shirasaki-nat444] 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.
2. Addressing Models
The key of addressing model is the address block between Customer
Premises Equipment (CPE) and Carrier Grade NAT (CGN)
[I-D.ietf-behave-lsn-requirements]. It's mentioned in this section.
The best addressing model is "ISP Shared Address" which is defined in
[I-D.shirasaki-isp-shared-addr] and briefly described in this
section.
2.1. Global Address
ISP cannot assign IPv4 Global Address any more after the exhaustion.
2.2. Private Address
It has two major problems.
2.2.1. Policy Based Routing Issue
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).
2.2.2. Address Block Duplication Issue
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.
2.2.3. Class-E Address (240/4)
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
Yamaguchi, et al. Expires January 12, 2012 [Page 3]
Internet-Draft NAT444 addressing models July 2011
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.
2.2.4. ISP Shared Address
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
[I-D.shirasaki-isp-shared-addr].
3. Example Architectures
This section explains example architectures how to design NAT444 with
ISP Shared Address.
3.1. Direct Routing inside CGN
This architecture enables direct communication between customers
inside same CGN. It has the following advantages.
o The packets don't go through CGN. (No hairpining)
o The customers inside CGN can use bidirectional applications (e.g.
TV Conference, VPN).
o No need to use Policy Based Routing.
(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|
+---------+ +---------+
Yamaguchi, et al. Expires January 12, 2012 [Page 4]
Internet-Draft NAT444 addressing models July 2011
3.2. CGN Bypassing
This architecture is bypassing the NAT function of CGN. It has the
following advantage.
o The customers inside an ISP can use bidirectional applications
(e.g. TV Conference, VPN).
o Any communication in single ISP doesn't consume CGN external port.
o ISP's servers outside CGN can access CPE. (e.g. ICMP echo, SNMP,
remote access)
o ISP's servers outside CGN can distinguish which customer's
connection it receives. (e.g. DNS, Mail)
(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|
+---------+ +---------+
Yamaguchi, et al. Expires January 12, 2012 [Page 5]
Internet-Draft NAT444 addressing models July 2011
3.3. Global Address Customers inside CGN
This architecture enables co-existing Global Address and ISP Shared
Address inside CGN.
It enables direct communications from ISP Shared Address customer to
Global Address customer inside same CGN. It has the following
advantage.
o The ISP can put ISP Shared Address customer and Global Address
customer in the same concentrator.
o The customers inside CGN can use bidirectional applications (e.g.
TV Conference, VPN).
o No need to use Policy Based Routing.
(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|
+-----------+ +---------+
4. Acknowledgements
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.
Yamaguchi, et al. Expires January 12, 2012 [Page 6]
Internet-Draft NAT444 addressing models July 2011
5. IANA Considerations
IANA is to allocate a certain size of address block from IANA free
pool. The size of it is described in [I-D.shirasaki-isp-shared-addr]
6. Security Considerations
There are no security considerations.
7. References
7.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.
[I-D.shirasaki-isp-shared-addr]
Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "ISP Shared Address",
draft-shirasaki-isp-shared-addr-05 (work in progress),
September 2010.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for IP address sharing
schemes", draft-ietf-behave-lsn-requirements-01 (work in
progress), March 2011.
[I-D.shirasaki-nat444]
Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J.,
and H. Ashida, "NAT444", draft-shirasaki-nat444-03 (work
in progress), January 2011.
7.2. Informative References
[PROP58] Niinobe, S., Tomochika, T., Yamaguchi, J., Nishino, D.,
Ashida, H., Nakagawa, A., and T. Hosaka, "Proposal to
create IPv4 shared use address space among LIRs", 2008,
<http://www.apnic.net/policy/proposals/
prop-058-v001.html>.
Yamaguchi, et al. Expires January 12, 2012 [Page 7]
Internet-Draft NAT444 addressing models July 2011
Authors' Addresses
Jiro Yamaguchi
Internet Initiative Japan Inc.
Kakyoin Square Bldg., 15F, 1-1-20 Kakyoin, Aoba-ku
Sendai 980-0013
Japan
Phone: +81 22 216 5650
Email: jiro-y@iij.ad.jp
Yasuhiro Shirasaki
NTT Communications Corporation
NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019
Japan
Phone: +81 3 6700 8530
Email: yasuhiro@nttv6.jp
Shin Miyakawa
NTT Communications Corporation
Granpark Tower 17F, 3-4-1 Shibaura, Minato-ku
Tokyo 108-8118
Japan
Phone: +81 3 6733 8671
Email: miyakawa@nttv6.jp
Akira Nakagawa
Japan Internet Exchange Co., Ltd. (JPIX)
Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku
Tokyo 100-0004
Japan
Phone: +81 90 9242 2717
Email: a-nakagawa@jpix.ad.jp
Yamaguchi, et al. Expires January 12, 2012 [Page 8]
Internet-Draft NAT444 addressing models July 2011
Hiroyuki Ashida
its communications Inc.
3-5-7 Hisamoto Takatsu-ku Kawasaki-shi
Kanagawa 213-0011
Japan
Email: ashida@itscom.ad.jp
Yamaguchi, et al. Expires January 12, 2012 [Page 9]