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

From: Matthew Ford <[email-masked]>
Date: Tue, 03 Mar 2009 22:04:22 +0000

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: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Mar 2009 13:07:48 +0100

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ó:
> ------------------------------------------------------------------------
>
> _______________________________________________
> shara mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shara

---

From: Matthew Ford <[email-masked]>
Date: Wed, 04 Mar 2009 14:29:23 +0000

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

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

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

> issues to take into account

Probably :)

> 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

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.

> CGNs probably more, but still

Good point.

> IP address space, i don't know how many IP addresses free will show

Hence my point about 'unknown viability'.

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

> 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

I'm not sure about that. RFC5382 specifies the requirements here doesn't it?

  - Mat

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 04 Mar 2009 15:48:29 +0100

Matthew Ford escribió:
> 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)

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

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

> 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'm not sure about that. RFC5382 specifies the requirements here 
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

---

From: Randy Bush <[email-masked]>
Date: Thu, 05 Mar 2009 09:55:21 +0900

perhaps we should be more concerned that cgn (well, KLSN, kinda largish
scale nat, as nats really do not scale well) is the permanent death of
the end2end internet and the permanent establishment of walled gardens.
and yes, permanent.  i assure you that the providers have no plan to
remove them in your lifetime.  some carriers see klsn as integral to
their permanent walled garden ngn deployment.

ipv6 transition, if it happens, will take a long time.  during that
time, we need to give the users the ability to have real internet
despite the cgn disaster the carriers are going to create in their
desperation.

so, we either need to give them a better plan or give the users an out.
shared port addressing can do either/both.

of course it has drawbacks.  that's life in engineering and operations.
insane ivory tower idealism is what got us into this damned v4/v6
incompatibility mess in the first place, get over it.

randy