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

Versions: 00 01 02

Network Working Group                                            T. Tsou
Internet-Draft                                 Huawei Technologies (USA)
Intended status: Standards Track                                  W. Liu
Expires: April 25, 2013                              Huawei Technologies
                                                            S. Perreault
                                                                Viagenie
                                                                R. Penno
                                                     Cisco Systems, Inc.
                                                                 M. Chen
                                                                 FreeBit
                                                        October 22, 2012


               Stateless IPv4 Network Address Translation
                     draft-tsou-stateless-nat44-02

Abstract

   This memo describes a protocol for decentralizing IPv4 NAT to the
   customer-premises equipment (CPE) such that no state information is
   kept on the central NAT device.  The CPE uses a restricted source
   port set that is encoded in its provisioned IPv4 WAN address.  The
   NAT device performs only strictly stateless address (not port)
   translation.

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 25, 2013.

Copyright Notice

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



Tsou, et al.             Expires April 25, 2013                 [Page 1]

Internet-Draft               Stateless NAT44                October 2012


   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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Address Formats  . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Customer Provisioning  . . . . . . . . . . . . . . . . . . . .  5
   5.  SLNAT44 Configuration  . . . . . . . . . . . . . . . . . . . .  6
   6.  Port Set Computation . . . . . . . . . . . . . . . . . . . . .  6
   7.  CPE Operation  . . . . . . . . . . . . . . . . . . . . . . . .  7
     7.1.  ALG Handling . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  SLNAT44 Operation  . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Internal to External . . . . . . . . . . . . . . . . . . .  8
     8.2.  External to Internal . . . . . . . . . . . . . . . . . . .  8
     8.3.  Fragment Handling  . . . . . . . . . . . . . . . . . . . .  9
   9.  Address Mapping Example  . . . . . . . . . . . . . . . . . . .  9
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     12.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11




















Tsou, et al.             Expires April 25, 2013                 [Page 2]

Internet-Draft               Stateless NAT44                October 2012


1.  Introduction

   IPv4 address exhaustion has become world-wide reality.  NAT is one of
   the solutions to deal with the problem.  The drawbacks of traditional
   NAT include statefulness and the need to track transport-layer
   sessions.  This makes NAT complex, hard to scale up, and fragile.

   This document describes a method of deploying stateless NAT as a
   backwards-compatible evolution of an IPv4-only network.

   The assumed topology is illustrated in Figure 1.

               +-----+                   +---------+
    Home  -----+ CPE |---<ISP network>---+ SLNAT44 +---- Internet
   network     +-----+                   +---------+
                     ^                             ^
                     |                             |
                     +-- Internal Address          +--- External Address

                    Figure 1: Stateless NAT44 topology

   When CPE is configured working as a transparent bridge, internal
   addresses are directly assigned to the end hosts in the home network,
   as is shown in Figure 2.

               +-----+                   +---------+
    Home  -----+ CPE |---<ISP network>---+ SLNAT44 +---- Internet
   network     +-----+                   +---------+
       ^                                           ^
       |                                           |
       +-- Internal Addresses                      +--- External Address

             Figure 2: Stateless NAT44 topology: CPE as bridge

   Note that SLNAT44 has no IPv6 component.  Any deployment of IPv6 is
   unaffected by SLNAT44.  Therefore, this document only describes IPv4
   addresses and IPv4 packets.  IPv6 is not discussed further.


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

   The following terms are used throughout this document:





Tsou, et al.             Expires April 25, 2013                 [Page 3]

Internet-Draft               Stateless NAT44                October 2012


   Port set:  Set of transport-layer ports that each CPE is assigned, to
      be used as source ports by packets sent by the CPE.

   Port Set ID:  A value from which a unique port set is algorithmically
      derived.

   SLNAT44:  Depending on the context, either the stateless NAT44
      protocol or the stateless NAT44 device that translates between
      internal and external addresses.  NAT44 in turn stands for "IPv4-
      to-IPv4 NAT".

   Internal Address:  The IPv4 address assignted to a CPE.  It is used
      in the ISP network between the CPE and the SLNAT44.

   External Address:  The IPv4 address used on the Internet and routed
      to the SLNAT44.

   Mapping rule:  A set of parameters configured on the SLNAT44 (not on
      the CPE) describing the relationship between internal and external
      addresses.


3.  Address Formats

   Internal addresses have the format illustrated in Figure 3.  The
   addresses are simply made of three parts concatenated together: the
   Internal Prefix, the External Suffix, and the Port Set ID.

   |0                    |a                                        |32
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Internal Prefix   |    External Suffix    |   Port Set ID   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: Internal Address format

   External Addresses have the format illustrated in Figure 4.  It is
   made of two parts: the External Prefix and the External Suffix.

   |0                                      |b                      |32
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              External Prefix          |    External Suffix    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 4: External Address format

   The lengths of the Internal and External Prefixes, "a" and "b", are
   mandatory parameters of SLNAT44.  They are determined by the ISP.
   They need not be communicated to the CPE.  Other lengths can be



Tsou, et al.             Expires April 25, 2013                 [Page 4]

Internet-Draft               Stateless NAT44                October 2012


   computed from them as follows:

   o  Length of External Suffix: 32 - b

   o  Length of Port Set ID: b - a


4.  Customer Provisioning

   Customer Provisioning is applied to the CPE when the CPE serves a
   gateway.

   As part of its start up routine, the CPE is assigned an IPv4 address
   by the ISP using regular means (DHCP, PPP, etc.).  This is the
   Internal Address.

   In addition, using new provisioning options, the CPE is assigned a
   Port Set ID.

   Optionally, a Port Set Mask is also provisioned to the CPE.  This
   mask is of the same length as the Port Set ID (i.e., b-a bits).  Its
   purpose is to allow discontinuous port ranges.  If no mask is
   provided, a mask of all ones is assumed by default, which implies a
   continuous port range.  System ports (0-1023) should not to be
   assigned to any CPE.

   In summary, the CPE is provisioned with the following elements:

   o  IPv4 address (as usual)

   o  Port Set ID

   o  Port Set Mask (optional)

   When the CPE is configured in the bridge mode, all the above features
   are provisioned directly to the end host behind the CPE.

   Note: no matter in which mode the CPE is running, the customer
   provisioning could be either dynamic or static.  Static provisioning
   implies an address planning for the private IPv4 address (i.e.,
   RFC1918 addresses) inside in the domain.  Static provisioning enables
   servers (passive daemons) at the home network being accessible within
   the domain.  CPE running as bridge makes this feature easy to deploy
   while running as L3 gateway requires port redirection if an in-domain
   server at a host is demanded.






Tsou, et al.             Expires April 25, 2013                 [Page 5]

Internet-Draft               Stateless NAT44                October 2012


5.  SLNAT44 Configuration

   The SLNAT44 is configured with a set of mapping rules.  Each rule
   contains:

   o  Internal Prefix

   o  External Prefix

   o  Port Set Mask (optional)

   Prefixes include their length.  For simplicity, rule prefixes MUST
   NOT overlap with other rules.

   If it is absent, the Port Set Mask is assumed to be all ones by
   default.


6.  Port Set Computation

   Given a Port Set ID and a Port Set Mask, both n bits in length, the
   set of allowed ports is defined as the set of port numbers for which
   the higher-order n bits of their binary expression whose
   corresponding mask bits are 1 are equal to corresponding bits from
   the Port Set ID.

   |0        |5
   +-+-+-+-+-+
   |1 1 1 0 1|  Port Set ID = 29 (length n = 5 bits)
   +-+-+-+-+-+
    & & & & &
   +-+-+-+-+-+
   |1 1 1 1 1|  Port Set Mask
   +-+-+-+-+-+
    | | | | |
    V V V V V
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 1 0 1 x x x x x x x x x x x x|  Port Set = 59392-61439
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0                                |16

             Figure 5: Example Contiguous Port Set Computation









Tsou, et al.             Expires April 25, 2013                 [Page 6]

Internet-Draft               Stateless NAT44                October 2012


|0              |8
+-+-+-+-+-+-+-+-+
|0 0 1 0 1 1 1 1|  Port Set ID = 29 (length n = 8 bits)
+-+-+-+-+-+-+-+-+
 & & & & & & & &
+-+-+-+-+-+-+-+-+
|0 0 1 1 1 1 1 1|  Port Set Mask
+-+-+-+-+-+-+-+-+
 | | | | | | | |
 V V V V V V V V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x 1 0 1 1 1 1 x x x x x x x x x| Port Set = 12032-12287, 28416-28671,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+            44800-45055, 61184-61439
|0                                |16

           Figure 6: Example Non-Contiguous Port Set Computation

   It follows that the number of ports in the set is 2^(16-x), where x
   is the number of ones in the Port Set Mask.

   This computation is performed by the CPE as part of its provisioning
   routine as well as by the SLNAT44 for dropping packets with ports
   outside the allowed range.

   For the purposes of SLNAT44, a "source port" corresponds to either a
   TCP source port, a UDP source port, or an ICMPv4 identifier, while a
   "destination port" corresponds to either a TCP destination port, a
   UDP destination port, or an ICMPv4 identifier.  Note that an ICMPv4
   identifier plays the role of both source and destination port.

   Transport protocols other than TCP and UDP, as well as ICMPv4 types
   without an identifier field, are not supported.


7.  CPE Operation

   CPE can be configured as either a gateway or transparent bridge.

   In the gateway mode, packets sent from the CPE MUST have the
   provisioned IPv4 address as source and MUST have a source port that
   is within the allowed set.  This is usually accomplished by having
   the CPE run a NAT44 configured with the provisioned address and
   allowed port set and having it process all packets sent out the WAN
   interface.

   Packets received by the CPE on its WAN interface with a destination
   port outside the allowed range MUST be dropped.




Tsou, et al.             Expires April 25, 2013                 [Page 7]

Internet-Draft               Stateless NAT44                October 2012


   In the bridge mode, however, CPE only transfers packets and therefore
   the service of stateless NAT44 is performed by the SLNAT44 directly
   towards end hosts that possibly running as in-domain servers.

   Regardless of any mode of the CPE, the operation involves injecting
   private addresses (or prefixes) into the intra-domain backbone
   routing infrastructure.  It is necessary to operationally ensure that
   there are no private addresses/prefixes are leaking into the backbone
   route tables unless they are assigned by the SLNAT44 to CPEs or
   directly to hosts.

7.1.  ALG Handling

   If the CPE implements application level gateways (ALGs) such as FTP,
   RSTP or PPTP, it must ensure that ports present in the payload when
   tanslated fall within the allowed range.


8.  SLNAT44 Operation

8.1.  Internal to External

   When it receives a packet on an internal interface, the SLNAT44 finds
   the rule whose Internal Prefix matches the packet's source address.
   It extracts the Port Set ID from the packet's source address.  It
   then checks if the packet's source port is within the allowed set,
   using the rule's Port Set Mask.  If it is not, the packet MUST be
   dropped.

   If the packet's source port is within the allowed set, the SLNAT44
   builds the External Address by concatenating the rule's External
   Prefix with the External Suffix extracted from the packet's source
   address.  It then replaces the packet's source address with this
   External Address.  The IPv4 and transport-layer checksums are updated
   as necessary.  The packet is then forwarded as usual.

8.2.  External to Internal

   When it receives a packet on an external interface, the SLNAT44 finds
   the rule whose External Prefix matches the packet's destination
   address.  It then builds the Internal Address by concatenating the
   rule's Internal Prefix, the External Suffix extracted from the
   packet's destination address, and the Port Set ID computed by
   applying the rule's Port Set Mask to the packet's destination port's
   higher-order bits.  It then replaces the packet's destination address
   with this Internal Address.  The IPv4 and transport-layer checksums
   are updated as necessary.  The packet is then forwarded as usual.




Tsou, et al.             Expires April 25, 2013                 [Page 8]

Internet-Draft               Stateless NAT44                October 2012


8.3.  Fragment Handling

   If the incoming IP packet contains a fragment, then more processing
   may be needed.  This specification leaves open the exact details of
   how a SLNAT44 handles incoming IP packets containing fragments, and
   simply requires that the external behavior of the SLNAT444 be
   compliant with the following conditions.

   The SLNAT44 MUST handle fragments.  In particular, SLNAT44 MUST
   handle fragments arriving out of order, conditional on the following:

   o  The SLNAT44 MUST limit the amount of resources devoted to the
      storage of fragmented packets in order to protect from DoS
      attacks.

   o  As long as the SLNAT44 has available resources, the SLNAT44 MUST
      allow the fragments to arrive over a time interval.  The time
      interval SHOULD be configurable and the default value MUST be of
      at least 2 seconds.

   o  The SLNAT44 MAY require that the UDP, TCP, or ICMPv4 header be
      completely contained within the fragment that contains fragment
      offset equal to zero.

   For incoming packets carrying TCP or UDP fragments with a non-zero
   checksum, SLNAT44 MAY elect to queue the fragments as they arrive and
   translate all fragments at the same time.  In this case, the incoming
   tuple is determined as documented above to the un-fragmented packets.
   Alternatively, a SLNAT44 MAY translate the fragments as they arrive,
   by storing information that allows it to compute the necessary port
   number for fragments other than the first.  In the latter case,
   subsequent fragments may arrive before the first, and the rules (in
   the bulleted list above) about how the SLNAT44 handles (out-of-order)
   fragments apply.

   Implementers of SLNAT44 should be aware that there are a number of
   well-known attacks against IP fragmentation; see [RFC1858] and
   [RFC3128].  Implementers should also be aware of additional issues
   with reassembling packets at high rates, described in [RFC4963].


9.  Address Mapping Example

   An operator has two public ranges of size /18 and /19 called foo and
   bar respectively.  It plans to use 10/8 as its internal address
   prefix and PSID (port range) of length 5.  Two prefixes of the
   internal network




Tsou, et al.             Expires April 25, 2013                 [Page 9]

Internet-Draft               Stateless NAT44                October 2012


   The internal prefixes lengths are:

   o  32 - 18 - 5 = 13 (derived from foo)

   o  32 - 19 - 5 = 14 (derived from bar)

   This will give the following possible mappings:

   o  foo/18 <--> 10.0.0.0/13

   o  bar/19 <--> 10.128.0.0/14

   Author note: Discuss the where internal prefixes are overlapping


10.  Security Considerations

   The security considerations related to IP address sharing documented
   in RFC 6269 [RFC6269] and RFC 6056 [RFC6056] apply to SLNAT44.


11.  Acknowledgements

   Section 8.3 is adapted from [RFC6146].


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [RFC1858]  Ziemba, G., Reed, D., and P. Traina, "Security
              Considerations for IP Fragment Filtering", RFC 1858,
              October 1995.

   [RFC3128]  Miller, I., "Protection Against a Variant of the Tiny
              Fragment Attack (RFC 1858)", RFC 3128, June 2001.

   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
              Errors at High Data Rates", RFC 4963, July 2007.

   [RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-
              Protocol Port Randomization", BCP 156, RFC 6056,
              January 2011.



Tsou, et al.             Expires April 25, 2013                [Page 10]

Internet-Draft               Stateless NAT44                October 2012


   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.


Authors' Addresses

   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1 408 330 4424
   Email: tina.tsou.zouting@huawei.com


   Will Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com


   Simon Perreault
   Viagenie
   246 Aberdeen
   Quebec, QC  G1R 2E1
   Canada

   Email: simon.perreault@viagenie.ca


   Reinaldo Penno
   Cisco Systems, Inc.
   170 West Tasman Drivee
   San Jose, California  95134
   USA

   Email: repenno@cisco.com





Tsou, et al.             Expires April 25, 2013                [Page 11]

Internet-Draft               Stateless NAT44                October 2012


   Maoke Chen
   FreeBit
   3-6 Maruyama-cho
   Shibuya-ku, Tokyo  150-0044
   Japan

   Email: fibrib@gmail.com












































Tsou, et al.             Expires April 25, 2013                [Page 12]


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