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

Versions: 00 01 02 03 04 05 06 07 08

Internet Engineering Task Force                        Y. Shirasaki, Ed.
Internet-Draft                                               S. Miyakawa
Expires: April 30, 2009                               NTT Communications
                                                             A. Nakagawa
                                                        KDDI CORPORATION
                                                            J. Yamaguchi
                                                                     IIJ
                                                               H. Ashida
                                                                  iTSCOM
                                                        October 27, 2008


                     NAT444 with ISP Shared Address
               draft-shirasaki-nat444-isp-shared-addr-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of 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 April 30, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document describes a network model with ISP Shared Address and
   Carrier Grade NAT (CGN) called NAT444.  NAT444 is the only scheme not



Shirasaki, et al.        Expires April 30, 2009                 [Page 1]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Definition of NAT444 Model . . . . . . . . . . . . . . . . . .  3
   3.  Pros and Cons of NAT444 Model  . . . . . . . . . . . . . . . .  4
     3.1.  Pros of NAT444 Model . . . . . . . . . . . . . . . . . . .  4
     3.2.  Cons of NAT444 Model . . . . . . . . . . . . . . . . . . .  4
   4.  Address Block of ISP's Network . . . . . . . . . . . . . . . .  4
     4.1.  Global Address . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Private Address  . . . . . . . . . . . . . . . . . . . . .  4
       4.2.1.  Hairpining Issue . . . . . . . . . . . . . . . . . . .  4
       4.2.2.  Address Block Duplication Issue  . . . . . . . . . . .  5
     4.3.  Class-E Address (240/4)  . . . . . . . . . . . . . . . . .  5
     4.4.  ISP Shared Address . . . . . . . . . . . . . . . . . . . .  5
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  6
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  6
   Appendix A.  Example IPv6 Transition Scenario  . . . . . . . . . .  6
   Appendix B.  Example Architectures . . . . . . . . . . . . . . . .  9
     B.1.  Direct Routing inside CGN  . . . . . . . . . . . . . . . .  9
     B.2.  CGN Bypassing  . . . . . . . . . . . . . . . . . . . . . . 10
     B.3.  Global Address Customers inside CGN  . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 13














Shirasaki, et al.        Expires April 30, 2009                 [Page 2]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


1.  Introduction

   IPv4 address is said to be run out soon.  Unless ISP takes any
   action, it will not be able to provide the service to new customers.

   This document explains a NAT444 model.  This model is base on the
   environment where customers have been using Private Address [RFC1918]
   inside their CPE, and 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.

   It triggers ISPs to take actions for keeping assigning IPv4 address
   to their customers using non-Global IPv4 Address.  NAT444 is one of
   the solutions for this issue.


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 Carrier Grade NAT
   (CGN) [I-D.nishitani-cgn].  CGN is supposed to be installed in the
   ISP's network.

   The first IPv4 address block is Private Address inside CPE.  The
   second one is a IPv4 Address block between CPEs and CGN.  It could be
   Global Address, Private Address (10/8), Class-E (240/4)
   [I-D.wilson-class-e], or (newly defined) ISP Shared Address.  The
   third one is IPv4 Global Addresses that is outside CGN and directly
   connected to the IPv4 Internet.

                         ( The IPv4 Internet )
                     [ISP-A]                [ISP-B]
                        |                      |
   IPv4 Global Address  |                      |  IPv4 Global Address
                   +----+----+            +----+----+
                   |   CGN   |            |   CGN   |
                   +----+----+            +----+----+
   Any IPv4 Address     |                      |  Any IPv4 Address
                   +----+----+            +----+----+
                   | CPE NAT |            | CPE NAT |
                   +----+----+            +----+----+
   IPv4 Private Address |                      |  IPv4 Private Address
                   +----+----+            +----+----+
                   |IPv4 Host|            |IPv4 Host|
                   +---------+            +---------+



Shirasaki, et al.        Expires April 30, 2009                 [Page 3]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


3.  Pros and Cons of NAT444 Model

3.1.  Pros of NAT444 Model

   This network model has following advantages.

   - This is the only network model that doesn't require replacing CPEs
   those are owned by customers.
   - This network model is composed of the present technology.
   - This model doesn't require address family translation.
   - This model doesn't require DNS rewriting.

3.2.  Cons of NAT444 Model

   This network model has some technical restrictions.

   - Some application such as SIP and FTP 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.
   - Because both IPv4 route and IPv6 route exist, it doubles the number
   of IGP route inside the CGN.
   - UPnP doesn't work with double NAPTs.


4.  Address Block of ISP's Network

   The address block mentioned in this section is the one between CPE
   and CGN.  The best address block is "ISP Shared Address" which is
   defined in [I-D.shirasaki-isp-shared-addr] and briefly described in
   this section.

4.1.  Global Address

   ISP cannot assign IPv4 Global Address any more after the exhaustion.

4.2.  Private Address

   It has two major problems.

4.2.1.  Hairpining 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



Shirasaki, et al.        Expires April 30, 2009                 [Page 4]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


   CGN, ISP has to use Policy Based Routing (PBR).

4.2.2.  Address Block Duplication Issue

   The Private Address in ISP's network could conflict with its
   customer's network address.  Most 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.

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

4.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]


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


6.  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]


7.  Security Considerations

   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.




Shirasaki, et al.        Expires April 30, 2009                 [Page 5]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


   If a Global Address of the CGN is listed on the blacklist, other
   customers who share the same address could be affected.


8.  References

8.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.shirasaki-isp-shared-addr]
              Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida,
              "ISP Shared Address after IPv4 Address Exhaustion",
              draft-shirasaki-isp-shared-addr-00 (work in progress),
              June 2008.

   [I-D.nishitani-cgn]
              Nishitani, T. and S. Miyakawa, "Carrier Grade Network
              Address Translator (NAT) Behavioral Requirements for
              Unicast UDP, TCP and ICMP", draft-nishitani-cgn-00 (work
              in progress), July 2008.

   [I-D.wilson-class-e]
              Wilson, P., Michaelson, G., and G. Huston, "Redesignation
              of 240/4 from "Future Use" to "Private Use"",
              draft-wilson-class-e-02 (work in progress),
              September 2008.

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


Appendix A.  Example IPv6 Transition Scenario

   The steps of IPv6 transition are as follows.

   Step 1: Enabling softwire client in host




Shirasaki, et al.        Expires April 30, 2009                 [Page 6]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


   ISP provides IPv6 connectivity to customers with softwire [RFC4925].
   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.

        (The IPv4 Internet)  (The IPv6 Internet)
                 |                    | IPv6
                 |        +-----------+-----------+
                 |        | Softwire Concentrator |
                 |        +-----------+-----------+
                 +---------+----------+  ^
       IPv4 Global Address |             :
                +----------+----------+  :
                |         CGN         |  :
                +----------+----------+  :
   IPv4 ISP Shared 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|
           +---------------------------------+

   Step 2: Enabling softwire client in CPE

   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.




















Shirasaki, et al.        Expires April 30, 2009                 [Page 7]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


        (The IPv4 Internet)    (The IPv6 Internet)
                 |                      | IPv6
                 |           +----------+------------+
                 |           | Softwire Concentrator |
                 |           +----------+------------+
                 +---------+------------+  ^
    IPv4 Global Address    |               :
                +----------+------------+  :
                |         CGN           |  : IPv6 over IPv4 Softwire
                +----------+------------+  : (e.g. IPv6 over IPv4 L2TP)
   IPv4 ISP Shared Address |               :
     (ISP Network)         |               v
           +---------------+--------------------+
           |IPv4 NAT/IPv6 Softwire client in CPE|
           +---------------+--------------------+
    IPv4 Private Address / |
    IPv6 Dual Stack        |
               +-----------+-------------+
               |IPv4/IPv6 Dual Stack host|
               +-------------------------+

   Step 3: Moving on to dual stack

   ISP provides dual stack access to CPE.  A CPE uplink is now dual
   stack.

          (The IPv4 Internet)    (The IPv6 Internet)
                   |                       |
                   +---------+             |
      IPv4 Global Address    |             |
                    +--------+--------+    |
                    |       CGN       |    | IPv6
                    +--------+--------+    |
   IPv4 ISP Shared Address / |             |
      IPv6 Dual Stack        +-------------+
       (ISP Network)         |
             +---------------+----------------+
             |  IPv4 NAT/IPv6 Dual Stack CPE  |
             +---------------+----------------+
      IPv4 Private Address / |
      IPv6 Dual Stack        |
                 +-----------+-------------+
                 |IPv4/IPv6 Dual Stack host|
                 +-------------------------+

   Step 4: Moving on to pure IPv6

   IPv6 transition completes.



Shirasaki, et al.        Expires April 30, 2009                 [Page 8]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


   (The IPv6 Internet)
            |
       IPv6 |
   +--------+----------+
   |     IPv6 CPE      |
   +--------+----------+
       IPv6 |
   +--------+----------+
   |     IPv6 host     |
   +-------------------+


Appendix B.  Example Architectures

   This section explains example architectures how to design NAT444 with
   ISP Shared Address.

B.1.  Direct Routing inside CGN

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

   - The packets don't go through CGN.  (No hairpining)
   - The customers inside CGN can use bidirectional applications (e.g.
   TV Conference, VPN).
   - 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|
         +---------+            +---------+








Shirasaki, et al.        Expires April 30, 2009                 [Page 9]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


B.2.  CGN Bypassing

   This architecture is bypassing the NAT function of CGN.  It has the
   following advantage.

   - The customers inside an ISP can use bidirectional applications
   (e.g.  TV Conference, VPN).
   -Any communication in single ISP doesn't consume CGN external port.
   -ISP's servers outside CGN can access CPE. (e.g.  ICMP echo, SNMP,
   remote access)
   -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|
         +---------+            +---------+

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

   - The ISP can put ISP Shared Address customer and Global Address
   customer in the same concentrator.
   - The packets don't go through CGN.  (No hairpining)



Shirasaki, et al.        Expires April 30, 2009                [Page 10]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


   - The customers inside CGN can use bidirectional applications (e.g.
   TV Conference, VPN).
   - 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|
      +-----------+           +---------+


Authors' Addresses

   Yasuhiro Shirasaki (editor)
   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
   Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku
   Tokyo  163-1421
   Japan

   Phone: +81 3 6800 3262
   Email: miyakawa@nttv6.jp








Shirasaki, et al.        Expires April 30, 2009                [Page 11]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


   Akira Nakagawa
   KDDI CORPORATION
   GARDEN AIR TOWER, 3-10-10, Iidabashi, Chiyoda-ku
   Tokyo  102-8460
   Japan

   Email: ai-nakagawa@kddi.com


   Jiro Yamaguchi
   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


   Hiroyuki Ashida
   its communications Inc.
   3-5-7 Hisamoto Takatsu-ku Kawasaki-shi
   Kanagawa  213-0011
   Japan

   Email: ashida@itscom.ad.jp

























Shirasaki, et al.        Expires April 30, 2009                [Page 12]


Internet-Draft       NAT444 with ISP Shared Address         October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Shirasaki, et al.        Expires April 30, 2009                [Page 13]


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