[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-nishitani-cgn) 00 01 02 03 04 05 06 07 08 RFC 6888

Internet Engineering Task Force                              I. Yamagata
Internet-Draft                                               S. Miyakawa
Intended status: BCP                                  NTT Communications
Expires: April 21, 2011                                      A. Nakagawa
                                          Japan Internet Exchange (JPIX)
                                                               H. Ashida
                                                                  iTSCOM
                                                        October 18, 2010


           Common requirements for IP address sharing schemes
                 draft-ietf-behave-lsn-requirements-00

Abstract

   This document defines common requirements of multiple types of Large
   Scale Network Address Translation (NAT) that handles Unicast UDP, TCP
   and ICMP.

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 April 21, 2011.

Copyright Notice

   Copyright (c) 2010 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
   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



Yamagata, et al.         Expires April 21, 2011                 [Page 1]

Internet-Draft               Large Scale NAT                October 2010


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The policy of assignment of LSN external IP address, port
       and identifier . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Requirements for UDP . . . . . . . . . . . . . . . . . . . . .  7
   5.  Requirements for TCP . . . . . . . . . . . . . . . . . . . . .  8
   6.  Requirements for ICMP  . . . . . . . . . . . . . . . . . . . .  9
   7.  Identifying particular users (BOTs, spammers, etc) . . . . . .  9
     7.1.  Store Translation Log  . . . . . . . . . . . . . . . . . .  9
     7.2.  Fixed port assignment  . . . . . . . . . . . . . . . . . . 10
   8.  Considerations about limiting the number of LSN external
       ports  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 11
     12.2. Informative Reference  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12


























Yamagata, et al.         Expires April 21, 2011                 [Page 2]

Internet-Draft               Large Scale NAT                October 2010


1.  Introduction

   Now there are several IPv4 address sharing schemes such as Large
   Scale NAT (as known as NAT444[I-D.shirasaki-nat444-isp-shared-addr])
   , DS-Lite[I-D.ietf-softwire-dual-stack-lite], A+P[I-D.ymbk-aplusp]
   and so on under the discussion.

   Those IPv4 address sharing schemes are intended to be used in the
   middle of the ISP access network against IPv4 address shortage
   problem by sharing one global IPv4 address by multiple users.
   Authors believe that there are common requirements among all IPv4
   address sharing schemes to make them "transparent" as much as
   possible.  At the BEHAVE working group of IETF, following RFCs have
   already defined to achieve maximum transparency at the residential
   CPE which has NAT function;

      - RFC4787 : NAT Behavioral Requirements for Unicast UDP

      - RFC5382 : NAT Behavioral Requirements for TCP

      - RFC5508 : NAT Behavioral Requirements for ICMP

   However so, because those RFCs are mainly aimed at residential CPE
   and any IPv4 address sharing schemes are a bit different from it, we
   believe that requirements for LSN and other schemes should be defined
   alternatively to those RFCs.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   Readers are expected to be familiar with [RFC4787] and the terms
   defined there.  The following term are used in this document:

      Large-Scale NAT(LSN): NAT devices placed between CPE and public
      Internet by an operator.  LSN converts CPE IP Address, CPE Port,
      and CPE Identifier into LSN external IP Address, LSN external Port
      and LSN external Identifier in communication between CPE and GGN
      external.

      LSN external realm: The realm where IPv4 global addresses are
      assigned

      LSN internal realm: The realm placed between LSN and CPEs




Yamagata, et al.         Expires April 21, 2011                 [Page 3]

Internet-Draft               Large Scale NAT                October 2010


      LSN external IP address: The IP address on LSN in LSN external
      realm mapping to CPE IP address

      LSN external port: The port on LSN in LSN external realm mapping
      to CPE port

      LSN external identifier: The identifier of ICMP on LSN in LSN
      external realm mapping to CPE identifier

      Customer Premises Equipment(CPE): The terminal which is placed in
      LSN internal realm and may establish TCP sessions to LSN external
      realm (e.g. a single PC or NATBox)

      CPE IP address: The IP address on CPE in LSN internal realm

      CPE port: The port on CPE in LSN internal realm

      CPE identifier: CPE's identifier of ICMP in LSN internal realm

      CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port
      Service Server (SS) The server an operator supplies various
      services for CPE

      Service Server (SS): The server placed in external realm

      Service Provide Server (SPS): The server placed in external realm
      and controlled by LSN administrators



                           ++------++
                           |   SS   |
                           ++------++
                               |
                               |
                               |
   LSN external IP address Y1  |
   LSN external port y1        |
                           ++------++  LSN external realm
               ........... |  LSN   |...............
                           ++------++  LSN internal realm
                               |
   CPE IP address X1           |
   CPE port x1                 |
                           ++------++
                           |  CPE   |
                           ++------++




Yamagata, et al.         Expires April 21, 2011                 [Page 4]

Internet-Draft               Large Scale NAT                October 2010


                           Figure 1. LSN network


3.  The policy of assignment of LSN external IP address, port and
    identifier

   A LSN has a pool of LSN external IP addresses, ports and identifiers.
   CPEs share LSN external IP addresses.  Each LSN occupies combination
   of LSN external IP address, LSN external port and LSN external
   identifier exclusively.  For a fair use of limited resources, LSN has
   a limitation for the number of the LSN external ports per CPE.  LSNs
   need to keep high transparency to continue existing services after
   LSN is introduced.  Requirement of high transparency for LSN leads to
   high scalability of LSN.  High transparency means LSN basically keeps
   communications among CPEs except effect of limitations of the number
   of LSN external ports and TCP sessions.

   A CPE MAY apply UDP hole punching or TCP hole punching for
   interactive services among CPEs like Voice over IP and P2P. LSN
   SHOLUD NOT interfere in services using UDP hole punching or TCP hole
   punching.

   REQ-1: A LSN MUST allocate one external IP address to each CPE.

      a) LSN external IP address allocated to the CPE MUST be same for
      the UDP, TCP and ICMP.

   Justification: If a LSN allocates multiple LSN external IP addresses
   to each CPE, some applications might not work.

   REQ-2: A LSN MUST allocate LSN external ports which is mapped for CPE
   ports of UDP.

      a) A LSN MUST NOT overload LSN external port while a NAT UDP
      mapping timer does not expire.

      b) A LSN MAY reuse LSN external port after a NAT UDP mapping timer
      expires.

      c) A LSN SHOULD limit the number of the LSN external ports of UDP
      per CPE.

      d) The number of the LSN external ports of UDP per CPE which LSN
      can allocate SHOULD be configurable for the administrator of LSN.

   Justification: CPEs can communicate to CPE external realm fairly by
   limiting the number of LSN external ports per CPE.




Yamagata, et al.         Expires April 21, 2011                 [Page 5]

Internet-Draft               Large Scale NAT                October 2010


   REQ-3: A LSN MUST allocate LSN external ports which is mapped for CPE
   ports of TCP.

      a) A LSN MUST NOT overload LSN external port while the port is
      allocated for one or more TCP sessions originated by another CPE.

      b) A LSN MAY reuse LSN external port while the port is allocated
      for no session originated by any CPE.

      c) A LSN SHOULD limit the number of the LSN external ports of TCP
      per CPE.

      d) The number of the LSN external ports of TCP per CPE SHOULD be
      an administratively configurable option.

      e) A LSN SHOULD limit the number of the new sessions of TCP per
      time unit and per CPE.

   Justification: CPEs can communicate to CPE external realm fairly by
   limiting the number of LSN external ports per CPE.  In addition, TCP
   LSN external port MAY have TCP sessions, and therefore the TCP
   session timer is necessary for every 5-Tuple.  LSN can have not only
   the limitations of the number of LSN external ports but also TCP
   sessions per CPE.  Thus a LSN can prevent denial of service attacks
   with the tons of TCP open and close by malicious CPEs.

   REQ-4: A LSN MUST allocate LSN external identifiers which is mapped
   for CPE identifiers of ICMP.

      a) A LSN MUST NOT overload LSN external identifier before an ICMP
      Query session timer expires.

      b) A LSN MAY reuse LSN external identifier after an ICMP Query
      session timer expires.

      c) A LSN SHOULD limit the number of the LSN external identifier
      allocated per CPE.

      d) The number of the LSN external identifiers per CPE which LSN
      can allocate SHOULD be an administratively configurable option.

   Justification: CPEs can communicate to CPE external realm fairly by
   limiting the number of LSN external identifiers every CPE.

   If a CPE has already consumed many LSN external ports, the CPE might
   not use new ports because LSNs limit the number of ports.

   REQ-5: A LSN MAY have implementations that some specific applications



Yamagata, et al.         Expires April 21, 2011                 [Page 6]

Internet-Draft               Large Scale NAT                October 2010


   can work well even if each CPE's usable number of LSN external ports
   have already consumed.

   Justification: Some specific applications don't work well due to
   limitation of number of number of ports by LSN, therefore other
   applications might be affected in the same CPE.

   In Section 8 we discuss in detail.


4.  Requirements for UDP

   [RFC4787] describes requirements of the Unicast UDP of a NAT, and the
   behavior of "Endpoint-Independent Filtering "is RECOMMNEDED, and a
   NAT MUST have an "Endpoint-Independent Mapping" behavior to ensure
   transparency of LSN.

   To have "Endpoint-Independent Filtering" and "Endpoint-Independent
   Mapping" behaviors for LSNs, LSNs help to establish UDP Hole Punching
   among CPEs.  In other words, the possibility of the establishment of
   UDP Hole Punching among CPEs which have LSN is equal to the
   possibility among CPEs which don's t have LSN.  If LSNs have an
   "Address-Dependent Mapping" or "Address and Port-Dependent Mapping"
   behavior, the possibility that establishment of UDP Hole Punching is
   less than when LSNs have an "Endpoint-Independent Mapping" behavior.
   If LSNs have an "Address and Port-Dependent Filtering" behavior, the
   possibility that establishment of UDP Hole Punching is less than when
   LSNs have an "Endpoint-Independent Filtering" or "Address Dependent
   Filtering" behavior.

   If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs
   in LSN internal realm of the same LSN.



     X1:x1
     +------+ from X1:x1 to X2':x2'
     | CPE1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>++----++X1':x1'
     +------+                            |      |
                                         |  L   |
                                         |  S   |
      X2:x2                              |  N   |
     +------+ from X1':x1' to X2:x2      |      |
     | CPE2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<++----++X2':x2'
     +------+


                           Figure 2. Hairpinning



Yamagata, et al.         Expires April 21, 2011                 [Page 7]

Internet-Draft               Large Scale NAT                October 2010


   REQ-6: A LSN SHOULD comply with [RFC4787] for unicast UDP, unless a)
   applies.

      a)It is RECOMMENDED that a NAT have "Endpoint-Independent
      Filtering" behavior.

      Status: "If application transparency is most important, it is
      RECOMMENDED that a NAT have Endpoint-Independent Filtering
      behavior.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have Address-Dependent
      Filtering behavior." is written at REQ-8 in RFC4787.

   Justification: LSN which is placed at ISP/Carrier makes much of
   transparency.  In particular, for applications that receive media
   simultaneously from multiple locations (e.g., gaming), or
   applications that use rendezvous techniques.  But to be more precise,
   in the LSN case, it may not be needed for some specific protocol such
   as DNS query and response.


5.  Requirements for TCP

   [RFC5382] describes requirements of TCP of a NAT, and the behavior of
   "Endpoint-Independent Filtering" is RECOMMNEDED, and a NAT MUST have
   an "Endpoint-Independent Mapping" behavior to ensure transparency of
   LSN

   To have "Endpoint-Independent Filtering" and "Endpoint-Independent
   Mapping" behaviors for LSNs, LSNs help to establish TCP Hole Punching
   among CPEs.  In other words, the possibility of the establishment of
   TCP Hole Punching among CPEs which have LSN is equal to the
   possibility among CPEs which don's t have LSN.  If LSNs have an
   "Address-Dependent Mapping" or "Address and Port-Dependent Mapping"
   behavior, the possibility that establishment of TCP Hole Punching is
   less than when LSNs have an "Endpoint-Independent Mapping" behavior.
   If LSNs have an "Address and Port-Dependent Filtering" behavior, the
   possibility that establishment of TCP Hole Punching is less than when
   LSNs have an "Endpoint-Independent Filtering" or "Address Dependent
   Filtering" behavior.

   If a LSN supports NAT Hairpinning, a CPE can communicate other CPEs
   in LSN internal realm of the same LSN.

   REQ-7: A LSN SHOULD comply with [RFC5382] for TCP, unless a) applies.

      a) It is RECOMMENDED that a NAT have an "Endpoint independent
      filtering" behavior for TCP.




Yamagata, et al.         Expires April 21, 2011                 [Page 8]

Internet-Draft               Large Scale NAT                October 2010


      Status: "If application transparency is most important, it is
      RECOMMENDED that a NAT have an "Endpoint independent filtering"
      behavior for TCP.  If a more stringent filtering behavior is most
      important, it is RECOMMENDED that a NAT have an "Address dependent
      filtering" behavior." is REQ-3 in RFC5382.

   Justification: LSN which is placed at ISP/Carrier makes much of
   transparency.  But to be more precise, in the LSN case, it may not be
   needed for some specific protocols.


6.  Requirements for ICMP

   [RFC5508] describes requirements of ICMP of a NAT.  And there MAY be
   a case that CPE cannot establish communication from CPEs to LSN
   external realm because LSN limits the number of LSN external ports,
   identifiers and TCP sessions per CPE.  It is useful if CPE can
   distinguish an error to occur by the limitation of the LSN external
   ports, identifiers and TCP sessions from other errors.

   REQ-8: A LSN SHOULD comply with [RFC5508] for ICMP.

   Justification: LSN SHOULD have to keep high transparency for ICMP.
   And CPE MAY use P2P and interactive services between CPEs after a LSN
   is introduced.

   Therefore, written in [RFC5508], when a LSN can't establish new
   session of TCP/UDP by limiting of TCP/UDP ports per user, the LSN
   sends an ICMP destination unreachable message, with code of 13
   (Communication administratively prohibited) to the sender.


7.   Identifying particular users (BOTs, spammers, etc)

   It is necessary for network administrators to identify a user from an
   IP address and a timestamp in order to deal with abuse and lawful
   intercept.  When multiple users share one external address at LSN,
   the source address and the source port that are visible at the
   destination host are translated ones.  The following mechanisms can
   be used to identify the user that transmitted a certain packet.

7.1.  Store Translation Log

   One mechanism stores the following information at LSN.

      - destination address





Yamagata, et al.         Expires April 21, 2011                 [Page 9]

Internet-Draft               Large Scale NAT                October 2010


      - destination port

      - translated source address

      - translated source port

      - untranslated source address

      - untranslated source port

      - timestamp

   In such environment that one LSN accommodates a lot of users or
   processes large amount of traffic, the amount of log will be so large
   and the operator has to prepare large volume of storage.

7.2.  Fixed port assignment

   To save costs for storage, one can adopt this port assignment
   mechanism at LSN.  By fixing the range of external port per user/CPE,
   and having the mapping of internal IP address to external IP address
   and port, there will be no need to store per session log.  Note that
   this mechanism is possible only if the source port is known as well
   as the source address, the destination address and the destination
   port.


8.  Considerations about limiting the number of LSN external ports

   As discussed in section 3,4 and 5, LSN limits the number of LSN
   external ports and identifier per CPE.  Therefore some important
   applications like DNS might not work well due to applications
   consuming many LSN external ports.

   There are two ways to solve this issue.  The one is that particular
   applications are out of the targets for the number of port limitation
   for LSN.  In the case, the applications should be configurable for
   the administrator of LSN.

   The other is that LSN doesn't translate address or port for some
   specific applications, moreover it doesn't limit the number of LSN
   external ports.(we call "LSN pass-through") Therefore, LSN behave as
   a router.  In this case, some specific applications are out of
   limitation for the number of LSN external ports.  Some applications,
   which don't work well due to address translation like FTP, is
   effective.  Reducing costs of translation is also effective.  As a
   condition, administrators of LSN can control SPS which become a
   target of LSN pass-through.



Yamagata, et al.         Expires April 21, 2011                [Page 10]

Internet-Draft               Large Scale NAT                October 2010


     X1:x1             X1':x1'            X2:x2
     +---+from X1:x1  +---+fromX1:x1     +---+
     |   |to X2:x2    |   | to X2:x2     |   |
     | C |>>>>>>>>>>>>| L |>>>>>>>>>>>>>>| S |
     | P |            | S |              | P |
     | E |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| S |
     |   |from X2:x2  |   |fromX2:x2     |   |
     +---+ to X1:x1   +---+ to X1:x1     +---+



                        Figure 3. LSN pass-through

   No matter which solutions you choose, you should consider which
   applications you are out of limitation target for the number of LSN
   external ports.  When you choose too many applications, this might
   cause LSNs large load.


9.  IANA Considerations

   There are no IANA considerations.


10.  Security Considerations

   If malicious CPE can camouflage CPE 3-Tuple, the malicious CPE MAY
   prevent a normal CPE from sending data to external realm.  Therefore,
   an operator SHOULD make policies to prevent a spoofing of CPE
   3-tuple.


11.  Acknowledgements

   Thanks for the input and review by Tomohiro Nishitani, Yasuhiro
   Shirasaki, Takeshi Tomochika, Kousuke Shishikura, Dai Kuwabara,
   Tomoya Yoshida, Takanori Mizuguchi, Arifumi Matsumoto, Tomohiro
   Fujisaki and Dan Wing.


12.  References

12.1.  Normative References

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate



Yamagata, et al.         Expires April 21, 2011                [Page 11]

Internet-Draft               Large Scale NAT                October 2010


              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

   [RFC5508]  Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
              Behavioral Requirements for ICMP", BCP 148, RFC 5508,
              April 2009.

   [I-D.shirasaki-nat444-isp-shared-addr]
              Shirasaki, Y., Miyakawa, S., Nakagawa, A., Yamaguchi, J.,
              and H. Ashida, "NAT444 addressing models",
              draft-shirasaki-nat444-isp-shared-addr-04 (work in
              progress), July 2010.

12.2.  Informative Reference

   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
              Stack Lite Broadband Deployments Following IPv4
              Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work
              in progress), August 2010.

   [I-D.ymbk-aplusp]
              Bush, R., "The A+P Approach to the IPv4 Address Shortage",
              draft-ymbk-aplusp-05 (work in progress), October 2009.


Authors' Addresses

   Ikuhei Yamagata
   NTT Communications Corporation
   Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   Phone: +81 50 3812 4704
   Email: ikuhei@nttv6.jp




Yamagata, et al.         Expires April 21, 2011                [Page 12]

Internet-Draft               Large Scale NAT                October 2010


   Shin Miyakawa
   NTT Communications Corporation
   Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku
   Tokyo  108-8118
   Japan

   Phone: +81 50 3812 4695
   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


   Hiroyuki Ashida
   its communications Inc.
   541-1 Ichigao-cho Aoba-ku
   Yokohama  225-0024
   Japan

   Email: ashida@itscom.ad.jp
























Yamagata, et al.         Expires April 21, 2011                [Page 13]


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