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

Versions: 00 01 02 03 04 05 draft-ietf-behave-lsn-requirements

Internet Engineering Task Force                             T. Nishitani
Internet-Draft                                               S. Miyakawa
Expires: January 3, 2009                              NTT Communications
                                                            July 2, 2008


 Carrier Grade Network Address Translator (NAT) Behavioral Requirements
                     for Unicast UDP, TCP and ICMP
                         draft-nishitani-cgn-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 January 3, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   This document defines basic terminology for describing different
   types of carrier-grade Network Address Translation (NAT) behavior
   when handling Unicast UDP, TCP and ICMP.  Developing carrier-grade
   NATs that meet this set of requirements increase transparency of data
   between carrier networks.





Nishitani & Miyakawa     Expires January 3, 2009                [Page 1]


Internet-Draft              Carrier Grade NAT                  July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  The policy of assignment of CGN external IP address, port
       and identifier . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Unicast UDP Requirements . . . . . . . . . . . . . . . . . . .  8
   5.  TCP Requirements . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  ICMP Requirements  . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Summary of Requirements  . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 12
     11.2.  Informative Reference . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 15

































Nishitani & Miyakawa     Expires January 3, 2009                [Page 2]


Internet-Draft              Carrier Grade NAT                  July 2008


1.  Introduction

   Global IPv4 address from the IANA pool will run out in a few years,
   thus carriers need to shift from IPv4 services to IPv6 ones.
   However, IPv6 deployment seems to take a long time.

   NAT [RFC3022] is a key technology to utilize IPv4 global address
   effectively in current practice.  ISP may have to place NAT devices
   between end-users and the public Internet to suppress global IPv4
   address consumption.

   In this document, we call carrier's NAT device Carrier Grade NAT
   (CGN).  This document describes behavioral requirements of CGN for
   unicast UDP, TCP and ICMP.  [RFC4787], [I-D.ietf-behave-tcp] and
   [I-D.ietf-behave-nat-icmp] describes requirements of unicast UDP, TCP
   and ICMP for NAT which is placed on network edge and is intended for
   high transparency of NAT.  CGNs also need interoperability and high
   transparency among carriers to make end-users be able to use various
   services like Peer-to-Peer(P2P) applications and Instant Messenger.
   [RFC5128] is nominated for an NAT traversal condition in P2P.

   The main target of this document is 4-4-4 model which uses IPv4
   address both internal and external side of CGN.
   [I-D.durand-v6ops-natv4v6v4] describes 4-6-4 model, and CGN may apply
   to 4-6-4 model.

   Interaction of this requirements and security of Customer Premises
   Equipment(CPE) is out of scope because CPE should defend itself.


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:

      Carrier-grade NAT(CGN): NAT devices placed between CPE and public
      Internet by a carrier.  CGN converts CPE IP Address, CPE Port, and
      CPE Identifier into CGN external IP Address, CGN external Port and
      CGN external Identifier in communication between CPE and GGN
      external.

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




Nishitani & Miyakawa     Expires January 3, 2009                [Page 3]


Internet-Draft              Carrier Grade NAT                  July 2008


      CGN internal realm: The realm placed between CGN and CPEs

      CGN external IP address: The IP address on CGN in CGN external
      realm corresponding to CPE IP address

      CGN external port: The port on CGN in CGE external realm
      corresponding to CPE port

      CGN external identifier: The identifier of ICMP on CGN in CGN
      external realm corresponding to CPE identifier

      Customer Premises Equipment(CPE): The terminal which is placed in
      CGN internal realm and may establish TCP sessions to CGN external
      realm

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

      CPE port: The port on CPE in CGN internal realm

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

      CPE 3-tuple: The tuple of TCP/UDP, CPE IP address, and CPE Port
      Carrier Service Server (CSS) The server a carrier supplies various
      services for CPE

      Carrier Service Server (CSS): The server a carrier supplies
      various services for CPE



                           ++------++
                           |  CSS   |
                           ++------++
                               |
                               |
                               |
   CGN external IP address Y1  |
   CGN external port y1        |
                           ++------++  CGN external realm
               ........... |  CGN   |...............
                           ++------++  CGN internal realm
                               |
   CPE IP address X1           |
   CPE port x1                 |
                           ++------++
                           |  CPE   |
                           ++------++




Nishitani & Miyakawa     Expires January 3, 2009                [Page 4]


Internet-Draft              Carrier Grade NAT                  July 2008


                                CGN network


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

   A CGN has a pool of CGN external IP addresses, ports and identifiers.
   CPEs share CGN external IP addresses.  Each CGN occupies combination
   of CGN external IP address and CGN external port exclusively.  For a
   fair use of limited resources, CGN has a limitation for the number of
   the CGN external ports per CPE.  CGNs need to keep high transparency
   to continue existing services after a carrier introduces CGN.
   Requirement of high transparency for CGN leads to high scalability of
   CGN.  High transparency means CGN basically keeps communications
   among CPEs except effect of limitations of the number of CGN 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. CGN
   SHOLUD NOT interfere in services using UDP hole punching or TCP hole
   punching.

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

      a) CGN external IP address of the UDP, TCP and ICMP MUST be same.

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

   REQ-2: A CGN MUST allocate CGN external ports corresponding to CPE
   ports of UDP.

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

      b) A CGN MAY overload CGN external port after a NAT UDP mapping
      timer expires.

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

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

      e) A CGN SHOULD NOT allocate well-known ports as CGN external
      ports.

   Justification: CPEs can communicate to CPE external realm fairly by



Nishitani & Miyakawa     Expires January 3, 2009                [Page 5]


Internet-Draft              Carrier Grade NAT                  July 2008


   limiting the number of CGN external ports per CPE.

   REQ-3: A CGN MUST allocate CGN external ports corresponding to CPE
   ports of TCP.

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

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

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

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

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

      f) A CGN SHOULD NOT allocate well-known ports as CGN external
      ports.

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

   REQ-4: A CGN MUST allocate CGN external identifiers corresponding to
   CPE identifiers.

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

      b) A CGN MAY overload CGN external identifier after an ICMP Query
      session timer expires.

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

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

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



Nishitani & Miyakawa     Expires January 3, 2009                [Page 6]


Internet-Draft              Carrier Grade NAT                  July 2008


   When a CGN limits the number of CGN external ports and TCP sessions,
   CPE may not use TCP services during using web and P2P services.  For
   example, some services using Ajax demand few dozens of TCP sessions.
   P2P software like BitTorrent demands also TCP sessions more than few
   dozens.  Some CPEs MAY use E-mail services like POP3 and SMTP even
   though CPE uses the services which demand many TCP sessions at the
   same time.  Therefore it is important to reserve CGN external ports
   for such administratively configured services.

   REQ-5: Reserving CGN external ports per CPE for the always-available
   services are RECOMENDED.

      a) The destination port which is used for reservation of CGN
      external ports SHOULD be administratively configurable.

   Justification: To reserve the CGN external ports for specific
   services, CPE can avoid the effect of the limitation of CGN external
   ports by CGN.

   In addition, it MAY not be necessary to set a limit to the number of
   CGN external ports for the communications between CPEs and CSS.  The
   reason is because CGN should pass-through the communications between
   CPEs and CSS.


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



                               pass-through

   REQ-6: A CGN SHOULD pass-through the communication between CPEs and
   CSS.

   Justification: Using pass-through, CGN does not have to assign CGN
   external IP address, ports, and identifiers and limit to the number
   of ports and TCP sessions for the services that a carrier manages.







Nishitani & Miyakawa     Expires January 3, 2009                [Page 7]


Internet-Draft              Carrier Grade NAT                  July 2008


4.  Unicast UDP Requirements

   [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 CGN.

   To have "Endpoint-Independent Filtering" and "Endpoint-Independent
   Mapping" behaviors for CGNs, CGNs help to establish UDP Hole Punching
   among CPEs.  In other words, the possibility of the establishment of
   UDP Hole Punching among CPEs which have CGN is equal to the
   possibility among CPEs which don's t have CGN.  If CGNs have an
   "Address-Dependent Mapping" or "Address and Port-Dependent Mapping"
   behavior, the possibility that establishment of UDP Hole Punching is
   less than when CGNs have an "Endpoint-Independent Mapping" behavior.
   And if CGNs have an "Address and Port-Dependent Filtering" behavior,
   the possibility that establishment of UDP Hole Punching is less than
   when CGNs have an "Endpoint-Independent Filtering" or "Address
   Dependent Filtering" behavior.  Because a CSS is placed external CGN
   realm, the source IP address and port of the communication from CPE
   to CSS is CGN external IP address and port.  It is RECOMMENDED to use
   STUN[I-D.ietf-behave-rfc3489bis] if CPEs check the CGN external IP
   address and port for CPE.

   A carrier MAY introduce TURN [I-D.ietf-behave-turn] to support
   communications among CPEs.  If CGN supports "Hairpinning", CGN can
   hairpin the communications between CPEs in the same CGN.  Therefore
   the requirements of Hairpinning for CGN MAY reduce requirements for
   the performance of TURN servers.  When CPEs decide the course of UDP
   between CPEs, CPE MAY use [I-D.ietf-mmusic-ice] .



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


                                Haripinning

   REQ-7: A CGN SHOULD comply with [RFC4787] for unicast UDP.



Nishitani & Miyakawa     Expires January 3, 2009                [Page 8]


Internet-Draft              Carrier Grade NAT                  July 2008


   Justification: CGN SHOULD have to keep high transparency for unicast
   UDP communications.  And CPE MAY use P2P and interactive services
   between CPEs after a carrier introduces CGN.


5.  TCP Requirements

   [I-D.ietf-behave-tcp] 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 CGN

   To have "Endpoint-Independent Filtering" and "Endpoint-Independent
   Mapping" behaviors for CGNs, CGNs help to establish TCP Hole Punching
   among CPEs.  In other words, the possibility of the establishment of
   TCP Hole Punching among CPEs which have CGN is equal to the
   possibility among CPEs which don's t have CGN.  If CGNs have an
   "Address-Dependent Mapping" or "Address and Port-Dependent Mapping"
   behavior, the possibility that establishment of TCP Hole Punching is
   less than when CGNs have an "Endpoint-Independent Mapping" behavior.
   And if CGNs have an "Address and Port-Dependent Filtering" behavior,
   the possibility that establishment of TCP Hole Punching is less than
   when CGNs have an "Endpoint-Independent Filtering" or "Address
   Dependent Filtering" behavior.  Because a CSS is placed external CGN
   realm, the source of IP address and port of the communication from
   CPE to CSS is CGN external IP address and port.  It is RECOMMENDED to
   use STUN[I-D.ietf-behave-rfc3489bis] if CPEs want to check the CGN
   external IP address and port for CPE.

   A carrier MAY introduce TURN [I-D.ietf-behave-turn] to support
   communications among CPEs.  If CGN supports "Hairpinning", CGN can
   hairpin the communications between CPEs in the same CGN.  Therefore
   the requirements of Hairpinning for CGN MAY reduce requirements for
   the performance of TURN servers.  When CPEs decide the course of TCP
   between CPEs, CPE MAY use [I-D.ietf-mmusic-ice] .

   REQ-8: A CGN SHOULD comply with [I-D.ietf-behave-tcp] for TCP.

   Justification: CGN SHOULD have to keep high transparency for TCP
   communications.  And CPE MAY use P2P and interactive services between
   CPEs after a carrier introduces CGN.


6.  ICMP Requirements

   [I-D.ietf-behave-nat-icmp] describes requirements of ICMP of a NAT.
   And there MAY be a case that CPE cannot establish communication from
   CPEs to CGN external realm because CGN limits the number of CGN



Nishitani & Miyakawa     Expires January 3, 2009                [Page 9]


Internet-Draft              Carrier Grade NAT                  July 2008


   external ports, identifiers and TCP sessions per CPE.  It is useful
   if CPE can distinguish an error to occur by the limitation of the CGN
   external ports, identifiers and TCP sessions from other errors.

   REQ-9: A CGN SHOULD comply with [I-D.ietf-behave-nat-icmp] for ICMP.

      a) When a CGN can't establish new session of TCP/UDP by limiting
      of TCP/UDP ports per user, the CGN sends an ICMP destination
      unreachable message, with code of 13 (Communication
      administratively prohibited) to the sender.

   Justification: CGN SHOULD have to keep high transparency for ICMP.
   And CPE MAY use P2P and interactive services between CPEs after a
   carrier introduces CGN.  And it is necessary to be able to
   distinguish an error to occur by the limitation of the CGN external
   ports and TCP sessions from a network error.


7.  Summary of Requirements

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

      a) CGN external IP address of the UDP, TCP and ICMP MUST be same.

   REQ-2: A CGN MUST allocate CGN external ports corresponding to CPE
   ports of UDP.

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

      b) A CGN MAY overload CGN external port after a NAT UDP mapping
      timer expires.

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

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

      e) A CGN SHOULD NOT allocate well-known ports as CGN external
      ports.

   REQ-3: A CGN MUST allocate CGN external ports corresponding to CPE
   ports of TCP.

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




Nishitani & Miyakawa     Expires January 3, 2009               [Page 10]


Internet-Draft              Carrier Grade NAT                  July 2008


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

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

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

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

      f) A CGN SHOULD NOT allocate well-known ports as CGN external
      ports.

   REQ-4: A CGN MUST allocate CGN external identifiers corresponding to
   CPE identifiers.

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

      b) A CGN MAY overload CGN external identifier after an ICMP Query
      session timer expires.

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

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

   REQ-5: Reserving CGN external ports per CPE for the always-available
   services are RECOMENDED.

      a) The destination port which is used for reservation of CGN
      external ports SHOULD be administratively configurable.

   REQ-6: A CGN SHOULD pass-through the communication between CPEs and
   CSS.

   REQ-7: A CGN SHOULD comply with [RFC4787] for unicast UDP.

   REQ-8: A CGN SHOULD comply with [I-D.ietf-behave-tcp] for TCP.

   REQ-9: A CGN SHOULD comply with [I-D.ietf-behave-nat-icmp] for ICMP.

      a) When a CGN can't establish new session of TCP/UDP by limiting
      of TCP/UDP ports per user, the CGN sends an ICMP destination
      unreachable message, with code of 13 (Communication



Nishitani & Miyakawa     Expires January 3, 2009               [Page 11]


Internet-Draft              Carrier Grade NAT                  July 2008


      administratively prohibited) to the sender.


8.  IANA Considerations

   There are no IANA considerations.


9.  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,
   a carrier SHOULD make p olicies to prevent a spoofing of CPE 3-tuple.


10.  Acknowledgements

   Thanks for the input and review by Yasuhiro Shirasaki, Takeshi
   Tomochika, Kousuke Shishikura, Dai Kuwabara, Tomoya Yoshida, Takanori
   Mizuguchi.


11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              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.

   [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
              Peer (P2P) Communication across Network Address
              Translators (NATs)", RFC 5128, March 2008.

   [I-D.ietf-behave-tcp]
              Guha, S., "NAT Behavioral Requirements for TCP",
              draft-ietf-behave-tcp-07 (work in progress), April 2007.

   [I-D.ietf-behave-nat-icmp]
              Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
              Behavioral Requirements for ICMP protocol",



Nishitani & Miyakawa     Expires January 3, 2009               [Page 12]


Internet-Draft              Carrier Grade NAT                  July 2008


              draft-ietf-behave-nat-icmp-08 (work in progress),
              June 2008.

   [I-D.ietf-behave-rfc3489bis]
              Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for (NAT) (STUN)",
              draft-ietf-behave-rfc3489bis-15 (work in progress),
              February 2008.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [I-D.ietf-behave-turn]
              Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)",
              draft-ietf-behave-turn-08 (work in progress), June 2008.

11.2.  Informative Reference

   [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.durand-v6ops-natv4v6v4]
              Durand, A., "Distributed NAT for broadband deployments
              post IPv4 exhaustion", draft-durand-v6ops-natv4v6v4-01
              (work in progress), February 2008.


Authors' Addresses

   Tomohiro Nishitani
   NTT Communications Corporation
   Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku
   Tokyo  163-1421
   Japan

   Phone: +81 3 6800 3214
   Email: tomohiro.nishitani@ntt.com






Nishitani & Miyakawa     Expires January 3, 2009               [Page 13]


Internet-Draft              Carrier Grade NAT                  July 2008


   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











































Nishitani & Miyakawa     Expires January 3, 2009               [Page 14]


Internet-Draft              Carrier Grade NAT                  July 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).





Nishitani & Miyakawa     Expires January 3, 2009               [Page 15]


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