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

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

Matthew Ford escribió:
>
>> 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
>
> So taking the operator-led perspective I mentioned above, this could 
> be rephrased as: if the motivation is to not have to upgrade CPE, then 
> the extent to which CPE upgrades are required by the address-sharing 
> solution is interesting.
>
agree,
in the same line, if the port sharing approaches need to update the apps 
to continue working , or at least to continue working in the same way 
they do today)  (for instance apps using UPnP)

>> 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
>
> Good point.
>
>> 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?
>
> Hence my point about 'unknown viability'.
>
>> 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?
>
> Well, we have some survey data that suggests availability of 
> previously allocated space will be very restricted. Consumption rates 
> also tend to indicate that any relief would be short-lived. But you're 
> right, this assertion could use more hard evidence.
>
>> I mean, do we know how many address will be in a potential market?
>
> Who said anything about a market?
>

But this is one of the forms of getting more IPv4 public addresses and 
probably the one that would maximize the number of IPv4 addresses 
available, cause it has a direct incentive to make those addresses 
available. I mean, if i am a company that has for instance 3 /8 (to pick 
a random number), then i have no incentive what so ever to give these 
addresses to the community, while if there is an economic incentive for 
that, i may be more willing to make the right thing and give those 
addresses for those who are struggling to get them

>> 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 was assuming endpoint independent mapping, yes.

cause, i guess this another axe for discussion that has been considered 
in behave. With the IPv4 depletion, will we able to affrod endpoint 
independnce?
>
>> I think the discussion on nat endpoint independence should belong
>> somewhere...
>
> I'm not sure about that. RFC5382 specifies the requirements here 
> doesn't it?
>
right, but that was pre depletion, can we still afford that? (just 
asking, i like endpoint independence, and i think it is an important 
feature to have, but i guess the question will raise at some point)

Regards, marcelo

>  - Mat
>