Re: [shara] [Fwd: I-D Action:draft-ford-shared-addressing-issues-00.txt]

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

Hi Mat,

very nice document, i think it is very useful

Some comments, and many rants below



2.1.  IPv6 is the goal

   While we are discussing solutions to allow continued operation of the
   IPv4 Internet and the continued provision of services to IPv4-
   speaking customers, it is absolutely not the intention of this
   discussion to in any way advocate the prolongation of the life of
   IPv4 or to (further) delay the widespread adoption of IPv6.

But we are, right?
I mean, if we use some technique like these, the lifetime of ipv4 will 
be extended /that's the actual goal for this) and the need for IPv6 will 
be less.
I am not saying we should not do this, but i cannot avoid noticing the 
contradiction, when we claim that we are not delaying the IPv6 adoption 
by extending the lifetime of IPv4
As i see it, we are extending the lifetime of IPv4 and delaying the 
adoption of IPv6 cause it is simply the path of less resistance, the one 
that is cheaper in the short term. I think we will do this, cause there 
is not way to stop it.
But i think we should be honest about it
I think it does have a couple of side effects that are good for IPv6 
deployment though. If the tunnel technology used for PRR is IPv6, then 
ISPs will deploy IPv6 at least internally and that will foster IPv6 
deployment. I think that if we provide SHARA capabilities to NAT64, IPv6 
users will be as good as IPv4 users, at least in this aspect.

(in any case, i don't think my point is very relevant, since as i 
mention above, there is nothing we can do about it)

2.2.  Criteria for judging ISP responses

   On that basis, we believe that solutions to the problem of continuing
   to provide IPv4 service post-IPv4-address-completion should be judged
   on two primary criteria:

           1) The proximity of the end user to control over the impact
           of the solution on the end-to-end communication, and;

           2) The extent to which the solution affords a natural
           progression to widespread IPv6 deployment.


I agree with these criteria... i wonder if there are not additional 
issues to take into account
In particular, one thing that i guess it is imporntat is to what extent 
the proposed solutions break current applications. I mean, the goal of 
this is to continue providing service to IPv4 customers that don't want 
to move to IPv6 cause they don't want to upgrade their software. So, if 
the proposed solutions break current applications and require the 
customer to update patches to continue using their applications, it 
seems it would beat the purpose.
So, i think that understnading to what degree current applications 
continue woriking with the different type of solutions would be useful


 Rather,
   the discussion herein is intended to guide reactions to proposals
   that are being made as a pragmatic response to some very real
   problems looming for operators who need to be able to continue
   providing service to customers who do not have any IPv6 capable
   equipment and/or who want to access services that are only available
   via IPv4.

exactly!

2.3.1.  Obtaining previously-allocated addresses

   Acquisition of previously-allocated IPv4 addresses by whatever means
   is a strategy with currently unknown (but definitely limited)
   viability.

Right, but port sharing and cgn as well, right?
I mean, port sharing allows to multiple by 4 or by 10 the number of 
users per IP address?
CGNs probably more, but still

How much will be the address trade will provide it is not clear to me. I 
mean, there are some parties that have several /8s that i guess that may 
end up in the market, if there is economical reason for that. Once that 
there is an economical incentive for doing a more efficient use fo the 
IP address space, i don't know how many IP addresses free will show 
up.... do you?



 It is also impossible to estimate in advance the cost of
   such an approach, so it does nothing to minimise business risk.
   Acquiring previously-allocated addresses may provide a short-term
   tactical solution where a relatively small number of addresses are
   required urgently to address a specific need.

On what grounds do you claim this?
I mean, do we know how many address will be in a potential market?

 It cannot be a
   solution for long-term network business growth.  It is likely that
   previously-allocated blocks acquired by whatever means will be small
   and obtaining lots of contiguous small blocks may be impossible.
   This would inevitably lead to operational complexity and associated
   cost for the network taking this approach.  It is operationally
   unsustainable in anything but the short term.


2.3.3.  Shared address solutions


   However, some reduction of utility for IPv4-speaking Internet users
   is unavoidable in the future.  It is inevitable that a reduced number
   of ports will be available for individual end-user applications.
   Running servers on well-known ports will most probably be an activity
   that is restricted to users willing to pay a premium for a higher
   tier of service contract.  These may turn out to be good incentives
   for end-users to migrate to IPv6.

agree with this part of the IPv6 promotion

3.1.  Port Distribution, Port Reservation, Port Negotiation

  According to actual measurements the average number of outgoing ports
   per customer is much, much smaller than the maximum number of ports a
   customer can use at any given time.  However, the distribution is
   heavy-tailed, so there are typically a small number of subscribers
   who use a very high number of ports [CGN_Viability].  This means that
   an algorithm that dynamically allocates outgoing port numbers from a
   central pool is much more efficient than algorithms that statically
   divide the resource by pre-allocating a fixed number of ports to each
   subscriber.  Similarly, such an algorithm should be more able to
   accommodate users wishing to use a relatively high number of ports.

what are your assumptions about nat behaviour?
Are you considering NAT endpoint independent mapping here?
I think the discussion on nat endpoint independence should belong 
somewhere...


Matthew Ford escribió:
> All,
>
> Comments are very welcome on this recently submitted draft.
>
> Thanks,
> Mat
>
> -------- Original Message --------
> Subject: I-D Action:draft-ford-shared-addressing-issues-00.txt
> Date: Tue,  3 Mar 2009 03:45:01 -0800 (PST)
> From: [e-mail]
> Reply-To: [e-mail]
> To: [e-mail]
>
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>
>     Title           : Issues with ISP Responses to IPv4 Address 
> Exhaustion
>     Author(s)       : A. Durand, et al.
>     Filename        : draft-ford-shared-addressing-issues-00.txt
>     Pages           : 11
>     Date            : 2009-03-03
>
> The looming completion of IPv4 address allocations from IANA and the
> RIRs is already causing ISPs around the world to start to question
> how they will continue providing IPv4 service to IPv4-speaking
> customers when there are no longer sufficient IPv4 addresses to
> allocate them one per customer.  Several possible solutions to this
> problem are now emerging and this memo identifies important criteria
> to be borne in mind when evaluating these solutions.  We also seek to
> identify serious issues that remain even when mechanisms meeting our
> criteria are adopted.  We wish to stress that these solutions have a
> number of common, and potentially serious, issues.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ford-shared-addressing-issues-00.txt 
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> shara mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/shara