[ppml] "Who's afraid of IPv4 address depletion? Apparentlynoone."

michael.dillon at bt.com wrote:
>>I'm an ISP customer.  My IPv4 network isn't growing (maybe I 
>>add a /28 per year).  Tell me why I care about IPv6.
> 
> 
> A) If your ISP does not have IPv6 services ready when they can't
> get IPv4 addresses any more, they will be unable to add new 
> customers. 

There are more than enough tricks for an ISP to keep going in the face 
of global ipv4 shortage crunch, which will probably happen akin to a 
series of ever higher brick walls that will be hit and then scaled over.

1) Loosen up allocation requirements now

2) Churn will free them up when they are needed more

3) Scavenge all /30 public serial assignments

4) Offer unnumbered serial networking, possibly one public Loopback.

5) Offer only loopback public IP addresses or one to one natted over a 
barrier private network for the most common case of deployment.

6) customer firewalls become more uniformly usable with the only public 
ip addresses on loopback interfaces

7) Bring your own IP. Lots of different examples for this, I am 
specificaly referring to situations where ISP A has the customers and 
turns them up through ISP B, who up to the crunch was kind enough to 
address them out of B space, but will most likely not do that anymore.

8) /24 will likely cease to be a de-facto cutoff point from the BGP 
table if this continues past a certain point

8) Cross ISP tunneling of customer-carried-with IP blocks will likely 
become more common, if/when burden of providing anything more than 
de-minimis ipv4 addresses falls to the customer.


So for an example, an ISP who normal mode of assignment works like this.

T1/Leased line Customer, one /30 for WAN and one /29 for LAN, where the 
customer has its own firewall, can conceivably replace this inefficient 
waste of space with a couple /32's routed to loopback or over rfc1918 
barrier networks.

Scavenge/Churn one customer, turn up three to six more.

Broadband aggregation? Convert all your applicable users (all broadband 
agg ISP's have large percentages of these) to rfc1918, stick them behind 
a nat. Offer them ipv6 if they even want it. Easily done with pppoe 
customers.

Offer inbound port by port incoming service for that class of customer.

Pain? Effort? Aggravation? Greater turnup complexity? Yes to all of the 
above. But if resistance to ipv6 conversion continues, it may well prove 
to be worth it, for at least some ISP's.

And if most ISP's are in the same boat at the same time, then it wont be 
the huge competitive advantage it might otherwise be.

Globaly, there will be plenty of scavenging opportunities. And when the 
first brick wall in ipv4 availability is hit, allocation guidelines will 
probably change dramatically. The resulting scavenging will then have a 
much higher impact then, than it were, would it be done now, with 
current allocation guidelines.

Those with space from before will conceivably get much greater ground 
from these scavenging and miserly assignemnt strategies after the first 
brick wall is hit.

I think its unlikely that global ipv4 shortage would result in any 
technicaly proficient ISP from being able to turn up most new customers.

As a side benefit, the more pain involved in continuing with ipv4 
deployments, the more traction ipv6 will gain.

The real question I see, is does it become a good idea to preempt the 
scavenging neccessity and clamp the allocations and guidelines to 
produce scavenging sooner rather than later?

Sorta like highway driving while running low on gas, looking for that 
gas station open late night....when do you put the higher mpg tricks 
into effect, before or after you are in high adrenalin mode?

Joe