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

[<[e-mail]>]

Hi Marcelo, 

Thank you for your comments,please find my answers below: 

-----Message d'origine-----
De : marcelo bagnulo braun [mailto:[e-mail]] 
Envoyé : lundi 23 février 2009 10:38
À : LEVIS Pierre RD-CORE-CAE; BOUCADAIR Mohamed RD-CORE-CAE; GRIMAULT Jean-Luc RD-CORE-CAE; VILLEFRANQUE Alain RD-CORE-CAE; [e-mail]
Objet : comments about draft-levis-behave-ipv4-shortage-framework-00.txt

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?

PL> Yes you're right, in the case of IPv6-IPv4 translation the need to spare IPv4 public addresses still apply.


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)

PL> I first excluded this issue because I thought it was not the most urgent case, but re-considering it I guess you're right, it is indeed an important issue and I will not explicitly exclude it in the next version.

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?

PL> I need to add a sentence to make it clear, such as: "What needs to be considered is to what extent the IPv4 sharing solution makes use of IPv4 private addresses".
For example, if your solution is Double NAT, one NAT-level in the CPE and one NAT-level in the Network, you'll give private addresses to the CPEs, and some ISPs may encounter both an IPv4 public and an IPv4 private address shortage. This is one argument for DS-lite vs. Double NAT.


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?

PL> I will add in this paragraphe a sentence such as: "The impact on the IS platforms and applications handling the administrative and technical information to control the activation of services and to manage the customer profiles, should be evaluated and assessed."

And add also the following example:
"Common practice used to
   rely upon the global IPv4 address assigned to a CPE device for
   customer identification purposes.  The forthcoming address depletion
   therefore encourages ISPs to revisit their customer identification
   schemes since global IPv4 addresses will be shared amongst several
   customers."



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?

PL> Basically it is scalability, complexity, performance, cost. 
The main point if the number of entries you have. 
According to the solution it can vary from millions of entries (CGN) to almost no entries (port range with clever handling of port based routing -see Rémi Despres's proposal for instance-)
I will make it clearer.

Regards, marcelo


PL> Regards,

Pierre