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

Versions: 00 01 02 03 04

Network Working Group                                        W. Dec, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Informational                            March 27, 2011
Expires: September 28, 2011


                    Stateless 4Via6 Address Sharing
                       draft-dec-stateless-4v6-01

Abstract

   This document discusses the applicability and possible resolution of
   a number of issues attributed to A+P based solutions, specifically in
   the context of an IPv6 based solution characterised by this draft as
   a stateless 4Via6 (4V6) solution.  The document presents that the
   majority of the issues either do not apply to such stateless 4V6
   solutions, or are no worse that in alternative NAT44 based solutions.
   The few remaining issues can be mitigated by the solutions or
   operators.

Requirements Language

   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 RFC 2119 [RFC2119].

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 September 28, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Dec                    Expires September 28, 2011               [Page 1]

Internet-Draft                stateless 4V6                   March 2011


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.










































Dec                    Expires September 28, 2011               [Page 2]

Internet-Draft                stateless 4V6                   March 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Stateless 4-6-4 Technical and Architectual characteristics . .  4
   3.  Overview of issues and discussion  . . . . . . . . . . . . . .  7
     3.1.  Notion of Unicast Address  . . . . . . . . . . . . . . . .  7
       3.1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  Discussion . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Implementation on hosts  . . . . . . . . . . . . . . . . .  8
       3.2.1.  Overview . . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.2.  Discussion . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Non TCP/UDP port based IP protocols  . . . . . . . . . . .  8
       3.3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.2.  Analysis . . . . . . . . . . . . . . . . . . . . . . .  9
     3.4.  Provisioning and Operational Systems . . . . . . . . . . .  9
       3.4.1.  Overview . . . . . . . . . . . . . . . . . . . . . . .  9
       3.4.2.  Discussion . . . . . . . . . . . . . . . . . . . . . .  9
     3.5.  Training & Education . . . . . . . . . . . . . . . . . . . 11
       3.5.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 11
       3.5.2.  Discussion . . . . . . . . . . . . . . . . . . . . . . 11
     3.6.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.6.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 11
       3.6.2.  Discussion . . . . . . . . . . . . . . . . . . . . . . 12
     3.7.  Unknown Failure Modes  . . . . . . . . . . . . . . . . . . 13
       3.7.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 13
       3.7.2.  Discussion . . . . . . . . . . . . . . . . . . . . . . 13
     3.8.  Possible Impact on NAT66 use & design  . . . . . . . . . . 13
       3.8.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 13
       3.8.2.  Discussion . . . . . . . . . . . . . . . . . . . . . . 13
     3.9.  Port statistical multiplexing and monetization of port
           space  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
       3.9.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . 14
       3.9.2.  Discussion . . . . . . . . . . . . . . . . . . . . . . 14
     3.10. Readdressing . . . . . . . . . . . . . . . . . . . . . . . 15
       3.10.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 15
       3.10.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 15
     3.11. Ambiguity about communication between devices sharing
           an IP address. . . . . . . . . . . . . . . . . . . . . . . 16
       3.11.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 16
       3.11.2. Discussion . . . . . . . . . . . . . . . . . . . . . . 16
   4.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   7.  Contributors and Acknowledgements  . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19



Dec                    Expires September 28, 2011               [Page 3]

Internet-Draft                stateless 4V6                   March 2011


1.  Introduction

   As network service providers move towards deploying IPv6 and IPv4
   dual stack networks, and further on towards IPv6 only networks, a
   problem arises in terms of supporting residual IPv4 services, over an
   infrastructure geared for IPv6-only operations, and doing so in the
   context of IPv4 address depletion.  This class of problem is referred
   to by the draft as the 4via6 problem, to which a number of solutions
   have been put forward.  The solutions fall largely into two types of
   architectures characterized by the location of the IPv4 address
   sharing/overloading function.  As an example, the DS-lite solution
   [I-D.ietf-softwire-dual-stack-lite] relies on the use of a large
   scale stateful Address Family Transition Router (AFTR), capable of
   IPv4 address sharing, ie DS-Lite uses a centralized large scale port
   overloaded stateful NAT44, aka PAT44, that is deployed within the
   operators' core network.  In contrast, solutions such as a 4rd
   [I-D.despres-softwire-4rd] and dIVI [I-D.xli-behave-divi] rely on the
   use of fully distributed NAPT44 functionality located on end user
   CPEs, keeping the network operators' core effectively stateless.  The
   latter type of solutions, rely on the same IPv4 address being used by
   multiple CPEs, each with a different TCP/UDP port range, and are
   often referred to as being part of the Address+Port (A+P) solution
   space [I-D.ymbk-aplusp].  A number of issues have been claimed to be
   attributed to this type of technology & solution, eg
   [I-D.thaler-port-restricted-ip-issues], [A+P BoF], which have so far
   delayed standardization progress, and which this draft attempts to
   discuss and resolve.  Specifically, for the analysis the document
   assumes a number of architectural and technical characteristics,
   termed as the stateless 4via6 solution, as detailed in the following
   section.

   The term "stateless 4via6 solution" is a general reference to the
   class of A+P derivative solutions, such as 4rd
   [I-D.despres-softwire-4rd] and dIVI [I-D.xli-behave-divi], as well a
   subset of the original A+P solution [I-D.ymbk-aplusp].  The term
   NAPT44 is used to refer to IPv4-IPv4 Network Address Translation with
   port overloading.


2.  Stateless 4-6-4 Technical and Architectual characteristics

   The following architectural and technical characteristics assumed by
   this document, and evidenced in whole or in part by various stateless
   4via6 solution proposals such as 4rd, dIVI, SAM, besides
   architectural practice.  Figure 1 depicts the overall architecture
   with two IPv4 user networks connected via 4via6 CPEs that share an
   IPv4 address.




Dec                    Expires September 28, 2011               [Page 4]

Internet-Draft                stateless 4V6                   March 2011


    ?      User 1
       Private IPv4
      |  Network
      |
   O------------------O
   |     4V6 CPE      |
   | +-----+--------+ |
   | NAPT44|  IPv6  | `-.
   | +-----+  Adptn | |  -._ ,-------.                      ------.
   |       +--------+ |   ,-'         `-.                ,-'       `-.
   O------------------O  /   Routed     \   O---------O /   Public   \
                         /    IPv6       \  |Stateless|/     IPv4     \
                        (    Network      --+   6V4   +-   Network     )
                         \               /  | Gateway |\              /
   O------------------O  \              /   O---------O \             /
   |     4V6 CPE      |   ;".         ,-'                `-.       ,-'
   | +-----+--------+ | ,"   `-------'                      ------'
   | NAPT44|  IPv6  | ,"
   | +-----+  Adptn | |
   |       +--------+ |
   O---.--------------O
       |
         User 2
       Private IPv4
        Network
   Figure 1 - Generalized Stateless 4via6 system

   The stateless 4via6 system has the following characteristics:

   1.   On user network side the routed IPv6 service provider network is
        demarcated from the IPv4 user network with a dedicated 4V6 CPE.
        The CPE externally has only a native IPv6 interface to the SP
        network, and a native IPv4 interface towards the end user
        network.

   2.   Internally, the 4V6 CPE can be modelled as having a port
        restricted NAPT44 function coupled with a stateless IPv6
        adaptation function that is able to ferry the IPv4 traffic in/
        over the IPv6 interface, besides deriving 4V6 provisioning info
        from it.  The IPv6 adaptation function could be encapsulating
        packets in IPv4 or translating IPv4 packets, or a combination of
        both.

   3.   The IPv4 Internet is demarcated from the operator IPv6 network
        with one or more operator managed stateless 6v4 gateways that
        contain an IPv6 adaptation function (not detailed in the
        diagram) matching the one on the CPE.  Note: The stateless 6v4
        gateway can be directly at the CPE side edge of the operator



Dec                    Expires September 28, 2011               [Page 5]

Internet-Draft                stateless 4V6                   March 2011


        network, eg in an IP Edge router, or as shown some IP hops
        removed from the edge network.

   4.   The service provider has the all the necessary provisioning and
        accounting infrastructure to support a regular IPv6 deployment.
        CPE management operations, if any, are done using IPv6, however
        there is no per CPE or subscriber management required of the
        stateless 4via6 function, i.e. all stateless 4via6 can share the
        same service configuration, bar the IPv6 address naturally.

   5.   The network operator has the ability to assign an IPv6 prefix or
        IPv6 address to a CPE, and log such address assignment.

   6.   The shared IPv4 address and any port range is conveyed to the
        CPE as part of an IPv6 address or prefix, for example using
        [RFC6052], if not other IPv6 compatible encoding and a port
        indexing method.  For a single shared public IPv4 address and
        port range, only a single IPv6 address or prefix is assigned
        irrespective of the port range size, with the mapping between
        IPv6 and IPv4 domains being entirely algorithmic based on a well
        known indexing schema.

   7.   The solution's architecture does not require customer traffic
        flows to pass through specific gateways in the network, or do so
        symmetrically.

   8.   End user host's DO NOT implement any of the 4V6, or other
        address sharing technologies, nor are they addressed directly
        with a shared IPv4 address.  End user IPv4 hosts connected to
        the CPE receive unique private addresses assigned by the CPE,
        and it is the CPE that is directly addressed by the shared IPv4
        address.

   9.   The IPv6 Adaptation function is not multi homed to the same IPv6
        network.  The CPE itself may be multi homed, but it only has one
        IPv6 addressed interface for the stateless 4via6 application and
        IPv6 adaptation function.

   10.  A CPEs NAPT44 function is modified to operate in a shared
        address port-constrained NAPT44 mode, as per the detailed
        solution proposals.  No DNS64 or IPv6 aware ALGs, nor IPv4 ALGs
        are used or assumed.  Any IPv4 ALG functionality that the CPE
        may support, remain unaffected.  The CPE is expected to act as a
        DNS resolver proxy, using native DNS over IPv6 to the SP
        network.

   11.  Although orthogonal to the discussion of stateless 4V6, it is
        useful to note that the CPE is expected to have a native IPv6



Dec                    Expires September 28, 2011               [Page 6]

Internet-Draft                stateless 4V6                   March 2011


        interface to the end user network, with any of the end user IPv6
        hosts (single or dual stack) receiving IPv6 addresses from an
        IPv6 delegated prefix issued to the CPE.


3.  Overview of issues and discussion

   This section summarizes the issues attributed to an A+P, or port
   restricted scheme, along with a discussion of applicability to the
   assumed system and possible resolutions.  The summary of issues stem
   from [I-D.thaler-port-restricted-ip-issues] and associated
   discussions.

3.1.  Notion of Unicast Address

3.1.1.  Overview

   The issue, referred to as the "definition of a unicast address",
   relates to the notion that in a shared IPv4 address system, multiple
   hosts will be visible as having a single IPv4 address outside of the
   system.  This issue is a general characteristic of any NAPT44 based
   solution [I-D.ietf-intarea-shared-addressing-issues], including DS-
   Lite.  However, a more specific aspect of this issue in the context
   of an address sharing system is the possibility that a single host
   having multiple interfaces will be assigned the same IPv4 address
   (with different port ranges) on each of its interfaces.  It may also
   be that multiple hosts sharing an address find themselves on the same
   Layer 2 segment.  Either would impede hosts from working within the
   notion of known host IP stack and protocol implementations.

3.1.2.  Discussion

   A number of the characteristics of the 4via6 solution architecture
   cause the issues not to be applicable, key of which is that there is
   no expectation for any kind of end hosts to be part of the shared
   IPv4 address system.

   In the stateless 4via6 system, CPE nodes are assigned with a shared
   IPv4 address+port range by means of the unique IPv6 address,
   containing the embedded IPv4 address + port index, of that CPE node.
   The CPE node is in addition enabled to be running the port restricted
   NAPT44 function from the IPv6 derived address, a key characteristic
   of the solution.  On the IPv6 plane, the IPv6 address of the CPE is
   practically indistinguishable from any "regular" IPv6 address, and in
   fact any host that is not aware of it conveying an embedded IPv4
   address would be able to use this just like any other regular IPv6
   address, ie the 4via6 solution uses standard IPv6 addressing.  In
   terms of the IPv4 dimension, since the shared address and port index



Dec                    Expires September 28, 2011               [Page 7]

Internet-Draft                stateless 4V6                   March 2011


   are never used to address native IPv4 nodes or hosts, but instead
   uniquely assigned to a single NAPT44 function that is part of the
   CPEs, all legacy or other IPv4 hosts are not exposed to the presented
   issues.

   Going beyond the ascribed issue however, it appears desirable to have
   the 4via6 CPEs that are to be part of the shared system to be able to
   provide a hint to the network operator in terms of their special
   capability.  Such a hint can be a DHCPv6 Option Request Option, which
   would be useful to allow the DHCPv6 sub-system to also inform the CPE
   of any other stateless 4via6 system parameters.  A largely similar
   ORO option is currently being defined as part of
   [I-D.ietf-softwire-ds-lite-tunnel-option]

   Recommendation: Define a suitable DHCPv6 ORO for conveying the 4via6
   capability of a CPE.

3.2.  Implementation on hosts

3.2.1.  Overview

   The issue, as presented, relates to the need for modifications on end
   hosts or devices to support a port constrained mechanism and the
   overall impossibility of realizing such modifications.  Furthermore,
   host applications that attempt to bind to specific ports that are not
   part of the allowed port range will fail to do so and may also
   require modifications.

3.2.2.  Discussion

   As presented in Section 2 the solution assumes the use of a dedicated
   CPE implementing the 4via6 functionality within a port constrained
   mode and NAPT44.  Granted, CPE nodes will require to implement new
   functionality such as the IPv6 adaptation function, that is likely
   alongside introducing native IPv6 support.  However, any and all
   existing end user IPv4 devices (eg PCs, etc) will not affected.  Nor
   are such devices expected to behave in any way different from that of
   today, where they typically obtain a private rfc1918 address and
   multiplexed by a CPE using a NAPT44 function.

   In summary, the assumed 4via6 solution requires a specific 4via6 CPE
   but does not require any IPv4 host stack changes.

3.3.  Non TCP/UDP port based IP protocols







Dec                    Expires September 28, 2011               [Page 8]

Internet-Draft                stateless 4V6                   March 2011


3.3.1.  Overview

   This issue relates to the inability of using regular ICMP messages to
   "ping" an end-host that has been addressed with a shared IPv4
   address.  The issue can be generalized one applicable to any IP
   protocol that is not TCP/UDP port based, and also in terms of the
   ability of using such protocols from end hosts that are assigned a
   shared IPv4 address.

3.3.2.  Analysis

   The inability to ping a CPE from the IPv4 Internet is shared by other
   IPv4 address sharing mechanisms such as DS-Lite.  Thus, the issue is
   no better or worse in the case of the stateless 4via6 solution.  The
   same can be said of end user hosts using other non UDP/TCP port based
   protocols from behind a NAPT44 function, ie they will not function
   irrespective of address sharing or not.

   In relation to the above another aspect deserves to be highlighted.
   Throughout, in the 4via6 solution, the IPv6 address of the CPE can be
   used for operational activities, such as pinging.  Also, given that
   each CPE's IPv4 address + port range maps deterministically to an
   IPv6 address and vice versa, the solution actually facilitates
   customer troubleshooting in contrast to others, eg DS-Lite, where the
   mapping between IPv6 and IPv4 addresses is indeterminate.

3.4.  Provisioning and Operational Systems

3.4.1.  Overview

   The general claim of this issue is that a service providers'
   provisioning and accounting systems would need to [radically] evolve
   to deal with the notions of shared IPv4 addresses and port range
   constrains.

3.4.2.  Discussion

   The stateless 4via6 solution relies on a fully operational IPv6
   network, which on the IPv6 plane fundamentally does not differ from a
   regular IPv6 network, and the stateless 4via6 solution may be seen as
   an IPv6 application - devices connecting to the network, need unique
   IPv6 addresses which the network is able to provide.  In the 4via6
   solution it happens that these unique IPv6 addresses embed an IPv4
   address.  Hence, additional system enhancements that the stateless
   4via6 solution requires, over and above those simply needed to deploy
   and operate an IPv6 network, lie in the domain of supporting the
   provisioning of the IPv6 adaptation functionality of the CPEs.  This
   may require the operator to use DHCPv6, or other provisioning methods



Dec                    Expires September 28, 2011               [Page 9]

Internet-Draft                stateless 4V6                   March 2011


   such as IPv6CP, TR-69, in order to configure any relevant 4via6
   service parameters to a CPE.

   From an IPv4 perspective, an operator will likely want to have a
   management system capable of the assignment of IPv4 addresses to the
   shared pool, and tuning the re-use factor.  In this, the solution
   exhibits no grossly different characteristics than those of any
   system with an operator managed NAT44 function where similar
   management capabilities need to be introduced.

   One additional aspect of the stateless 4via6 solution needs to be
   highlighted.  On a par basis this solution requires less per
   subscriber management, accounting and logging capabilities than
   centralized NAPT44 alternatives such as DS-Lite, due to the
   following:

   o  The assignment of an IPv6 address that embeds a deterministic IPv4
      address and port range removes the need for the operator to
      perform any NAPT44 binding logging, ie the task of determining
      which user had a given IPv4 address and port at a given time is
      simply a matter of determining who had the corresponding IPv6
      address, rather than collecting large amounts of dynamic binding
      data.

   o  There is no need for the operator to manage NAPT44 binding data
      access and retention.

   o  Given the stateless nature of the 4via6 solution, all subscriber
      CPEs in an operator's domain can share exactly the same 4via6
      service configuration, i.e.  The operator does not need to be
      concerned with managing on a per user basis specific AFTR
      assignment and/or load balancing such users and throughout
      ensuring symmetric traffic flows throughout.

   o  The location of the NAPT44 function on the user's CPE, allows easy
      and direct management of the port mappings by the end user
      removing a need for the operator to introduce PCP
      [I-D.wing-softwire-port-control-protocol] (or similar) protocols
      in on AFTRs, and on CPE devices.  In effect the end user can
      retains control of any bindings, which could be via today's GUI,
      or UPnP IGDv2, or even PCP.

   o  As and when needed, a stateless 4via6 solution readily supports
      the assignment of an unshared IPv4 address, and full port control
      by the end user.  A similar capability with centralised NAPT44
      solutions involve onerous management of per subscriber
      configurations on the operator's AFTR.




Dec                    Expires September 28, 2011              [Page 10]

Internet-Draft                stateless 4V6                   March 2011


3.5.  Training & Education

3.5.1.  Overview

   The issue claims a concern with the need for developers and support
   staff to be trained & educated in dealing with a port constrained
   systems.

3.5.2.  Discussion

   There appear to be at least two levels of looking at this issue in
   the stateless 4via6 context.  On one level, it is perfectly true that
   developers and support staff will need to be trained with running/
   supporting a native IPv6 network, that is now a basis of the
   solution.  This however is an inherent aspect of deploying an IPv6
   network and applications.  On another level, support and developers
   need to familiarized with the NAPT44 characteristics of the system,
   that are not different from those already known about such systems
   today.  More specifically, there appears to be no such thing as a
   port unconstrained carrier grade NAPT44 system, in either tomorrow's
   stateless 4via6 or AFTR guises, or today's residential CPE NAPT44
   implementations that have an inherent hard set translation limit
   (often 1024 translation, corresponding to a usage of 1024 ports).
   That application developers should be trained to be reasonably
   conservative in the usage of ports is thus not an issue of the
   stateless 4via6 solution, but pretty much of any NAPT44 based
   solution, even those in use today.

   Another useful observation here is that the stateless 4via6 solution,
   actually allows an operator to retain existing troubleshooting
   procedures, given which today encompass CPE based NAPT44, rather than
   changing them radically to an AFTR.  Furthermore, it is possible to
   alleviate any port-range constrains for users by allocating more
   generous port ranges without the need to manage such users
   configuration on active core network devices (eg AFTR).

3.6.  Security

3.6.1.  Overview

   The issue relates to port randomization being used as a security
   mitigation for certain types of specialized attacks, as explained in
   [RFC6056] and the claim that a system with a restricted port range is
   grossly more vulnerable.







Dec                    Expires September 28, 2011              [Page 11]

Internet-Draft                stateless 4V6                   March 2011


3.6.2.  Discussion

   The claim that a stateless 4via6 solution grossyly affects security
   does not appear to be entirely accurate when considering the
   following i) the actual threat ii) a comparison to a centralized
   NAPT44 solution, at par value in terms of the number communicating of
   IP end-points (inside) utilizing the system iii) the ability to use
   native IPv6 as well as proposed extensions.

   Assuming all other information has already been aquired, and also the
   presence of no exploits, the basic security of IP protocols lies in
   the computational cost of guessing a combination of a protocol field,
   eg a TCP sequence number or say a DNS transaction ID, multiplied by a
   the cost of a guess of a source port.  Thus, for a TCP brute force
   attack, the already substantial cost in guessing a sequence number
   (2^32 possibilities) is multiplied by the port range guess cost.  In
   this context even a increase of say a 2^10 possibilities,
   corresponding for in a 1K port restricted 4V6 system, is costly
   enough for most practical purposes.  For a UDP/DNS brute force
   attack, the computational cost required to scan/generate the full
   range of 2^32 possibilities, corresponding to a port unrestricted
   system is relatively low/easy - today's GPUs can do so in a few
   seconds.  UDP/DNS can be said to be inherently vulnerable, with the
   solution residing in DNSec.  A 4V6 port restricted system would
   indeed lower such a computational cost, but for practical purposes it
   will still be in the order of seconds.  Moreover, for the case of
   UDP/DNS, the CPE is expected to us its DNS proxy resolver
   functionality, which acting on native IPv6, is totally unaffected by
   the port restriction, and thus any of the security claims.

   It's relevant to note that a fully range free random port choice of a
   centralized NAPT44 system is also something that is unlikely, at
   least in terms of it being guaranteed, and thus does not form a very
   strong basis against a port restricted system.  When a centralized
   NAPT44 function is multiplexing N end-points into a given outside
   IPv4 address, with an average of P ports per end-point, any given
   next flow from any of the end-points will be assigned to one of the
   (64k - N *P) available ports.  This is dependent on dynamic N and P
   values, and not just on P, and thus making the port selection a
   function of the number of end-points as is the case with a stateless
   4via6 solution.

   Beyond the above, in terms of the avoiding a fixed linear or single
   port range allocations, extensions to the 4V6 solution provides
   additional remedy, eg [I-D.bajko-pripaddrassign].

   In general thus, with a 4V6 solution it is possible to realize a
   viable level of security, which for practical purposes offers does



Dec                    Expires September 28, 2011              [Page 12]

Internet-Draft                stateless 4V6                   March 2011


   not and extending the 4V6 solution with .  It remains an area of
   possible further proposals for optional port range randomization
   methods to be combined in a 4V6 solution.

3.7.  Unknown Failure Modes

3.7.1.  Overview

   The issue purports that a system with a port constraints introduces
   new unknown failure modes, not known with NAT44 or NAPT44 systems,
   and in general is more complex than such a system.

3.7.2.  Discussion

   This claim does not appear to have objective technical arguments that
   can be discussed.  A restricted port range system, such as the one
   assumed in this document, does not appear to have any more or less
   complexity than any of the other NAPT44 solutions against which the
   same issue has not been levelled.  That is a statement that can be
   made in consideration of each of those alternative solution network
   design (eg elaborate routing rules or topologies) and feature
   implementation complexities, which appear to be no better than that
   of a stateless 4via6 address port range system.  Ultimately, system
   complexity is something best left adjudicated by the operators
   choosing to deploy one or the other of these IP based transition
   solutions.

3.8.  Possible Impact on NAT66 use & design

3.8.1.  Overview

   The notion of a shared address with a constrained port range is seen
   as possibly bearing influence on use in future schemes involving
   NAT66, where IPv6 address sharing is in general deemed not to be
   desired (ie there is good reason to avoid PAT66).

3.8.2.  Discussion

   The authors do not propose, nor expect to see the IP address sharing
   characteristic applying to future NAT66/PAT66 discussions and
   specification.  However, having said that it is useful to take a
   humble step back and consider the general aspect of causality in this
   context.  The direct cause that brought about IPv4 shared address
   solutions to the fore was a shortage/exhaustion of a limited IPv4
   address resource, alongside a failure of the community to migrate
   IPv4 networks to IPv6 in a timely manner.  At the time of writing it
   is hard to imagine the same occurring with respect to IPv6 address
   resources, and hopefully the same set of causes will not be allowed



Dec                    Expires September 28, 2011              [Page 13]

Internet-Draft                stateless 4V6                   March 2011


   to re-occur.  This appears to be the only way to ensure that IPv6
   address sharing effect does not come to be, as opposed to precluding
   such notions within the context of today's IPv4 world where the
   causality is rather clear.

3.9.  Port statistical multiplexing and monetization of port space

3.9.1.  Overview

   An issue attributed to port range constrained solutions is that due
   to their characteristic of assigning a fixed amount of ports to
   participating system nodes, the overall pool of ports cannot be
   dynamically/statistically multiplexed.

   A corollary of this claimed issue is the claim that port range
   constraints will lead to monetization by service providers of such
   port ranges, for example by charging users based on the number of
   ports assigned or creating some bronze, silver, gold type of port
   based service categories.  This is generally seen as an undesirable
   prospect due to it leading to "second class" Internet citizens(hip)
   in terms of a restriction of the ports utilizable by IP users.

3.9.2.  Discussion

   The 4via6 address shared solution indeed limits the ability to
   "overload" ie statistically multiplex amongst users, the ports
   available of a given public IPv4 address.  This can be seen as a
   trade off vs dynamic allocation and the need to log (large amounts)
   of NAT bindings.  Furthermore, the solution is meant to be
   fundamentally a transitional one for supporting legacy IPv4 users
   till full migration to IPv6 can occur.  As an example, even with a
   static allocation of ~1000 ports per shared IP user, it allows an
   operator to effectively multiply by ~64 the current IPv4 unrealizable
   address space.  To put it into a network growth perspective, it
   allows an operator to support for some 10 years a steady 50% annual
   increase in users, without requiring new IPv4 addresses.  This is
   likely an alluring (if unlikely) prospect for most, but it
   demonstrates the fact that even with static port allocations, IPv4
   address sharing can go a long way for many operators.

   In terms of the corollary of this issue, the monetization of port
   space, the authors do not consider this claim to apply specifically
   to the restricted port range solution.  It is a possibility that is
   and/all solutions that utilize NAPT44 technology allow.  In essence
   any operator can, should they choose to do so, "monetize ports" using
   existing NAT techniques, including DS-Lite AFTR, and thus render
   their users "second class" citizens.  This is a commercial decision,
   not a technical one, and does not appear to bear relevance to the



Dec                    Expires September 28, 2011              [Page 14]

Internet-Draft                stateless 4V6                   March 2011


   technical validity of a stateless 4via6 solution..  To draw an
   analogy, guns and cannons can be used in a reckless manner or not.
   Thus it appears to be highly unbalanced to claim that one technology
   (eg cannons/DS-Lite) can to be developed by the community, but not
   the other (eg guns/a 4via6 address sharing solution).

3.10.  Readdressing

3.10.1.  Overview

   Due to the port range encoding being part of the CPE's IPv6 address,
   any change in the range requires a re-configuration of the CPEs 4via6
   address.  This is said to be an issue given the impact that IP
   address changes have on existing traffic flows, as well as general
   IPv6 network routing

3.10.2.  Discussion

   It is true that under the assumed notions of the stateless 4via6
   solution, IPv6 re-addressing is required to effect a change in terms
   of the shared IPv4 address or ports.  Such changes can and are likely
   best done using dynamic address configuration methods such as DHCPv6,
   or alternatively out of band management tools, eg TR-69, especially
   when the 4via6 address can be derived from a delegated prefix.  Using
   these, the impact of the address change does not translate to a
   neither a classic IPv6 host renumbering problem nor an unmanageable
   network renumbering problem.  On the CPE, the change only affects the
   4via6 address of the CPE and not any end user IPv6 hosts behind the
   CPE (which would likely continue to derive their IPv6 addresses from
   an unchanged delegated prefix).  On the service provider network
   side, the change, if any, represents a network renumbering case which
   the operator can be reasonably expected to handle within their
   network numbering plan, especially given that the IPv6-prefix of the
   an IPv4-in-IPv6 address is summarizable.

   An addressing change will impacting any existing IPv4 flows that are
   being NAT'ed by the CPE.  This is also analogous to the today's
   practice of IPv4 address changes espoused by some operators, which
   while not being commendable, is established in the market.
   Nevertheless, as a means of alleviating such an impact it appears
   desirable for the solutions to investigate the viability of
   mechanisms that could allow for more graceful addressing changes.

   To facilitate IPv6 summarization and operator appears to have two 4V6
   deployment choices.  When encoding IPv4 addresses in lower order
   address space bits that are subject to summarization,the operator
   would need to assign a modest dedicated IPv6 prefix (such as a /64)
   as an 4V6 IPv6 addressing sub-domain.  Alternatively, without



Dec                    Expires September 28, 2011              [Page 15]

Internet-Draft                stateless 4V6                   March 2011


   resorting to a separate 4V6 addressing sub-domain, an operator could
   allow for the IPv4 address embedding to be embedded in a high-order
   portion of the IPv6 domain address space, one that closely follows
   the IPv6 domain prefix.  These two valid address subnetting and
   deployment options deserve better description in the solution
   specifications.

3.11.  Ambiguity about communication between devices sharing an IP
       address.

3.11.1.  Overview

   A regular IPv4 destination based routed system inherently does not
   allow two devices to communicate while sharing the same IPv4 address,
   even if with different ports.  Similarly, such a system does not
   allow on the basis of a IPv4 source address alone to perform address
   spoofing prevention.  These two issues naturally render regular IPv4
   based routed networks incapable of supporting a shared address
   solution.

3.11.2.  Discussion

   In terms of the IPv4 data plane of the 4via6 solution, the CPE and
   the stateless gateway components need to be modified in terms of
   their IPv4 forwarding behaviour.  The CPE's NAPT44 function, must be
   capable of sending traffic towards the IPv6 adaptation function when
   the traffic is addressed to its (shared) IPv4 address but a different
   port than the one assigned to the CPE.  Similarly, the CPE's NAPT44
   function must be capable of receiving traffic addressed from its
   (shared) IPv4 address but a different port than the one assigned to
   it.

   On the IPv6 data plane the stateless 4via6 solution does not suffer
   from the issue by the nature of relying on regular IPv6 forwarding.
   Address-spoofing security can be realized on regular IPv6 devices
   plane, in a way which effectively does not allow a CPE to send IPv6
   traffic from a source IPv6 address that it has not been assigned.
   The spoofing of IPv4 addresses can be prevented in this manner in
   4via6 solution relying on translation (dIVI).  Tunneling 4via6
   solutions (4rd) require IPv6+IPv4 source address validation to be
   performed at the CPE and stateless gateway, by the IPv6 adaptation
   function.

   The conceptual IPv6 adaptation function has many of its core
   principles already defined either as part of IPinIP tunneling or
   stateless NAT64 drafts.  However additional work, such as defining
   the port indexing schemes, is needed and is at the heart of what
   needs to be covered in the individual solution drafts that fall under



Dec                    Expires September 28, 2011              [Page 16]

Internet-Draft                stateless 4V6                   March 2011


   the stateless 4via6 family.  Throughout, no legacy IPv4 end-systems
   are expected to implement these techniques.


4.  Conclusion

   As per the discussion in this document, the authors believe that the
   set of issues specifically attributed to A+P based such as the
   stateless 4via6 solution with characteristics as per Section 2,
   either do not apply, or can be mitigated.  In several aspects, a
   stateless 4V6 solution represents a reasonable trade off compared to
   alternatives in areas such as NAT logging, ease as of deployment and
   operations, all of which are actually facilitated by such a solution.


5.  IANA Considerations

   This document does not raise any IANA considerations.


6.  Security Considerations

   This document does not introduce any security considerations over and
   above those already covered by the referenced stateless 4via6
   solution drafts.


7.  Contributors and Acknowledgements

   The authors thank Dan Wing, Jan Zorz, Satoru Matsushima, Qiong Sun,
   and Arkadiusz Kaliwoda for their review and feedback on the draft.


8.  References

8.1.  Normative References

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

8.2.  Informative References

   [I-D.bajko-pripaddrassign]
              Bajko, G., Savolainen, T., Boucadair, M., and P. Levis,
              "Port Restricted IP Address Assignment",
              draft-bajko-pripaddrassign-03 (work in progress),
              September 2010.




Dec                    Expires September 28, 2011              [Page 17]

Internet-Draft                stateless 4V6                   March 2011


   [I-D.despres-softwire-4rd]
              Despres, R., "IPv4 Residual Deployment across IPv6-Service
              networks (4rd) A NAT-less solution",
              draft-despres-softwire-4rd-00 (work in progress),
              October 2010.

   [I-D.ietf-intarea-shared-addressing-issues]
              Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing",
              draft-ietf-intarea-shared-addressing-issues-05 (work in
              progress), March 2011.

   [I-D.ietf-softwire-ds-lite-tunnel-option]
              Hankins, D. and T. Mrugalski, "Dynamic Host Configuration
              Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite",
              draft-ietf-softwire-ds-lite-tunnel-option-10 (work in
              progress), March 2011.

   [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-07 (work
              in progress), March 2011.

   [I-D.thaler-port-restricted-ip-issues]
              Thaler, D., "Issues With Port-Restricted IP Addresses",
              draft-thaler-port-restricted-ip-issues-00 (work in
              progress), February 2010.

   [I-D.wing-softwire-port-control-protocol]
              Wing, D., Penno, R., and M. Boucadair, "Pinhole Control
              Protocol (PCP)",
              draft-wing-softwire-port-control-protocol-02 (work in
              progress), July 2010.

   [I-D.xli-behave-divi]
              Li, X., Bao, C., and H. Zhang, "Address-sharing stateless
              double IVI", draft-xli-behave-divi-01 (work in progress),
              October 2009.

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

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.




Dec                    Expires September 28, 2011              [Page 18]

Internet-Draft                stateless 4V6                   March 2011


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


Author's Address

   Wojciech Dec (editor)
   Cisco Systems
   Haarlerbergweg 13-19
   1101 CH Amsterdam
   The Netherlands

   Email: wdec@cisco.com





































Dec                    Expires September 28, 2011              [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/