[shara] comments about draft-levis-behave-ipv4-shortage-framework-00.txt

[marcelo bagnulo braun <[e-mail]>]

Hi,

Thanks for writing this.

I have some comments and questions about this draft


In section 1.  Introduction it reads

   This document analyses the main issues related to IPv4 Internet
   access in the context of public IPv4 address exhaustion.  The IPv4
   Internet access from an IPv6 stack, and the IPv6 Internet access
   whatever the means, are out of the scope of this memo.


I am not sure why is that. I mean, the problem seems to exists in the 
case the the host is IPv6 and it is using an IPv6-IP^v4 trnaslator to 
access to the IPv4 Internet, right?


Then  in section 3.  Address Space Multiplicative Factor

   The purpose of sharing IPv4 addresses is to potentially increase the
   addressing space.  A key parameter is the factor by which ISPs want
   or need to multiply their IPv4 public address space; and the
   consequence is the number of customers sharing the same public IPv4
   address.

   The intention is not to replace IPv6.  However, we should be very
   careful; whatever the network model deployed, applications and
   business will run on top of it.  The fact that the IPv4 shortage
   mechanisms will not postpone IPv6 deployment, heavily relies on
   voluntarism.

While i agree with this, i think it is imporntat to understand the 
impact of the shara work on the IPv6 deployment. This is why i am 
puzzled that you haven't considered the shara problem for IPv6 only 
clients accessing the IPv4 Internet through an IPv4 IPv6 translator. 
Providing a solution for the shara problem to IPv4 only hosts and not 
providing a solution for IPv6 only hosts, will make staying in IPv4 even 
more attractive than migrating to IPv6.
So, i think that solving the share problem for IPv6 only hosts should be 
at least as important than solving it for the IPv4 clients (i do 
understand that solving it for IPv4 clients is more pressing, but 
solving it for the IPv6 clients is critical to not hinder the IPPv6 
deployment)


6.3.  Scarcity of Private Addressing

   According to [RFC1918], IPv4 private addresses must be chosen in the
   following ranges:

   o  10/8

   o  172.16/12

   o  192.168/16

   There is a potential of 2 at the power of (224 + 220 + 216)
   addresses, or 17,891,328 addresses.  Actually, private addresses are
   not that abundant when deployments are concerned.  Some ISPs already
   use private addresses within their networks for specific usage such
   as walled garden services, in a way they cannot reuse them for
   another usage.  As a consequence, the smallness of the IPv4 private
   address pool available for the Internet service could force some ISPs
   to use Virtual Private Networks (VPNs) such as [RFC4364] to allow
   reusing the same private addresses several times with no routing
   overlaps.  This brings a lot of complexity in network configuration
   and management.

   It has been suggested to make the 240./4 block available for private
   addressing [I-D.wilson-class-e].  This address block, formerly
   designated as "Class E", is still noted as being reserved in the IANA
   IPv4 address registry.  If it were reassigned for private addressing
   that would yield around 268 millions extra private addresses.
   However, many current implementations of the TCP/IP protocol stack do
   not allow the use of the 240./4 block.  This is a severe blocking
   point for a lot of existing devices: CPE, NAT or routers.  This issue
   will only be solved when the vendors' implementations accept the
   (240./4) addresses.

   Another suggestion [I-D.shirasaki-isp-shared-addr] is to reserve some
   public blocks (typically three or four /8) only for internal usage.
   So far, there has been no consensus upon this proposal.

So, what is the the exact aspect of this issue that needs to be 
considered when looking into IPv4 sharing solutions?


6.4.  Impact on Information System

   The IPv4 address shortage solutions could add port information in the
   Information System (IS) at different levels.  For instance, the
   possibility to give either a unique or a shared address, coupled or
   not with an IPv6 address, could yield several types of customers to
   deal with in the IS: IPv4 unique only, IPv4 shared only, IPv4 unique
   + IPv6, IPv4 shared + IPv6, IPv6 only.  The impact on the IS
   platforms and IS applications should be evaluated and assessed.


I don't understand what you mean by information system in this section, 
could you expand or include an example?

6.5.  Port Related Entries in the ISP Equipment

   Additional data related to port information should be stored and
   maintained by the ISP equipment.  As an example, a set of entries
   (e.g. session states, binding entries) are to be instantiated and
   maintained.  The logic instantiation (behavior and not necessarily
   detailed algorithms) of these entries should be standardized to avoid
   interoperability problems, and ease management tasks.  Optimization
   means for instantiating new entries should be investigated and
   deployed if required.  In addition, the amount of entries to be
   maintained should not be too big.

I am not sure what is the issue been considered here.... is the 
scalability of the solution or do you have some other issue in mind?

Regards, marcelo