[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Internet Engineering Task Force                        J. Yamaguchi, Ed.
Internet-Draft                                                       IIJ
Intended status: Informational                              Y. Shirasaki
Expires: September 9, 2010                                   S. Miyakawa
                                                      NTT Communications
                                                             A. Nakagawa
                                                        KDDI CORPORATION
                                                               H. Ashida
                                                                  iTSCOM
                                                           March 8, 2010


                        NAT444 addressing models
               draft-shirasaki-nat444-isp-shared-addr-03

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 to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 9, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the



Yamaguchi, et al.       Expires September 9, 2010               [Page 1]

Internet-Draft          NAT444 addressing models              March 2010


   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
   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 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 LSN . . . . . . . . . . . . . . . . . 4
     3.2.  LSN Bypassing . . . . . . . . . . . . . . . . . . . . . . . 5
     3.3.  Global Address Customers inside LSN . . . . . . . . . . . . 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 September 9, 2010               [Page 2]

Internet-Draft          NAT444 addressing models              March 2010


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 Large Scale NAT (LSN)
   [I-D.nishitani-cgn].  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 LSN,
   it has to go through LSN.  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 LSN for
   rewriting the source address from Private Address to Global Address.
   Additionally, if Private Address and Global Address co-exist inside
   LSN, 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 September 9, 2010               [Page 3]

Internet-Draft          NAT444 addressing models              March 2010


   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 LSN

   This architecture enables direct communication between customers
   inside same LSN.  It has the following advantages.

   o  The packets don't go through LSN.  (No hairpining)

   o  The customers inside LSN can use bidirectional applications (e.g.
      TV Conference, VPN).

   o  No need to use Policy Based Routing.



                 (The IPv4 Internet)
                          | Global Address
                     +----+----+
                     |   LSN   |
                     +----+----+
                          |
   ISP Shared +-----------+----------+ ISP Shared
      Address |      ..........      | Address
         +----+----+ :        : +----+----+
         | CPE NAT | :        : | CPE NAT |
         +----+----+ :        : +----+----+
      Private |      :        :      | Private
      Address |      v        v      | Address
         +----+----+            +----+----+
         |IPv4 Host|            |IPv4 Host|



Yamaguchi, et al.       Expires September 9, 2010               [Page 4]

Internet-Draft          NAT444 addressing models              March 2010


         +---------+            +---------+




3.2.  LSN Bypassing

   This architecture is bypassing the NAT function of LSN.  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 LSN external port.

   o  ISP's servers outside LSN can access CPE. (e.g.  ICMP echo, SNMP,
      remote access)

   o  ISP's servers outside LSN 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:
         |   LSN   | : bypass : |   LSN   | 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 September 9, 2010               [Page 5]

Internet-Draft          NAT444 addressing models              March 2010


3.3.  Global Address Customers inside LSN

   This architecture enables co-existing Global Address and ISP Shared
   Address inside LSN.

   It enables direct communications from ISP Shared Address customer to
   Global Address customer inside same LSN.  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 LSN can use bidirectional applications (e.g.
      TV Conference, VPN).

   o  No need to use Policy Based Routing.



   (The IPv4 Internet)
            |
            | Global Address
       +----+----+
       |   LSN   | 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 September 9, 2010               [Page 6]

Internet-Draft          NAT444 addressing models              March 2010


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]
              Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "ISP Shared Address",
              draft-shirasaki-isp-shared-addr-03 (work in progress),
              September 2009.

   [I-D.nishitani-cgn]
              Nishitani, T., Yamagata, I., Miyakawa, S., Nakagawa, A.,
              and H. Ashida, "Common Functions of Large Scale NAT
              (LSN)", draft-nishitani-cgn-03 (work in progress),
              November 2009.

   [I-D.shirasaki-nat444]
              Shirasaki, Y., Yamagata, I., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "NAT444", draft-shirasaki-nat444-00 (work
              in progress), October 2009.

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 September 9, 2010               [Page 7]

Internet-Draft          NAT444 addressing models              March 2010


Authors' Addresses

   Jiro Yamaguchi (editor)
   Internet Initiative Japan Inc.
   Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho, Chiyoda-ku
   Tokyo  101-0051
   Japan

   Phone: +81 3 5205 6500
   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
   KDDI CORPORATION
   GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku
   Tokyo  102-8460
   Japan

   Email: ai-nakagawa@kddi.com












Yamaguchi, et al.       Expires September 9, 2010               [Page 8]

Internet-Draft          NAT444 addressing models              March 2010


   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 September 9, 2010               [Page 9]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/