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

[Matthew Ford <[e-mail]>]

Thanks for the feedback Marcelo. A few responses inline below:

On 4/3/09 12:07, marcelo bagnulo braun wrote:
> 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.

Shared-addressing solutions, if they come to pass, should be nothing 
more than a stopgap. My motivation here is to identify in as precise and 
thorough a manner as possible the costs of shared-addressing solutions. 
Maybe when those costs are all out in the open people will start to take 
the need for IPv6 deployment a little more seriously.

> (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)

You just joined the IAB - you need to leave more room for your defeatism 
to grow :)

> 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

Probably :)

> 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.

Actually I'm not sure that is the primary motivation. I think it is more 
about operators that can't see a way to continue growing their business 
with IPv4 *or* IPv6. I think there's a lot more pressure that needs to 
be put on vendors to deliver missing IPv6 functionality, but I can 
understand operators wanting to cover their bets to some extent, given 
that time is running out.

> 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.

> 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?

> 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.

> 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?

  - Mat