[menog] IPv4 March 2011 depletion

[Owen DeLong]

On Nov 15, 2010, at 6:26 AM, Brian Candler wrote:

> On Mon, Nov 15, 2010 at 04:53:38AM -0800, Owen DeLong wrote:
>> As long as you
>> have NAT44 services on a segment, why would you put an IPv6-only
>> host on the same segment? There's nothing to be gained by such an action
>> other than pain and confusion.
> 
> It seems to me to be the only way to offer a phased rather than big-bang
> approach to migration on a particular subnet, such as the subnet which sits
> behind a home user's ADSL router.
> 
Again, I'm not understanding the need to phase a subnet. I can understand
phasing large or complex environments by doing them a subnet at a time,
but, phasing within a subnet strikes me as a recipe for greater pain and
complexity with minimal benefit in most environments. Especially in a
residential environment.

> As for enterprises, most have already deployed RFC1918 and NAT44 widely.  So
> whilst turning on native IPv6 alongside it ought to be moderately easy, it
> also doesn't yet offer any particular business reason to do so.
> 
Key word being yet. However, if you wait until the need arises, you are going to be
way behind the power curve trying to catch up.

> As you say, new subnets could be built as IPv6+NAT64, if they're happy to
> take the pain.  A decent NAT64 gateway would be necessary not only to access
> The Internet, but to access their own internal IPV4-only services.
> 
What would be the alternative? If you can't get IPv4 addresses for that new subnet,
you pretty much have to put it on IPv6 with NAT64 or deploy it with DS-LITE.

>>> AFAICS, the types of "forcing" required would be:
>>> a. ISPs cease to offer V4 services at all (not even NAT44)
>> 
>> Which will happen when ISPs don't have any more external IPv4 numbers to
>> use for NAT44 services.
> 
> If you put each DSLAM behind a single IP address, in theory you gain a 200:1
> improvement in your utilisation.  You probably can't do much better than
> that because of PAT port limitations, and in any case some of those users
> will want (and pay for) their own V4 address, but it's probably enough to
> deploy V4+NAT44 indefinitely using your existing address space.
> 
That theory breaks when you have users that want to use iTunes and Google
Maps among other applications. The workable ratio discovered by ISPs that
have been conducting these experiments has proven to be closer to 40:1.

This ignores several realities of how addresses are utilized. Right now,
NAT is considered tenable by end users for the following reasons:

1.	It doesn't break too many things.
2.	They have workarounds for most of the important things it does break.
3.	They can control port-forwarding or use tools like UPNP to work around NATs
	problems.

When you go to this style of NAT, you break all three of those assertions at the
same time. If you really think customers will not complain about this, your
competitors are now salivating over your soon to be former customers.

> You can also put loopbacks on your servers instead of having service
> subnets.  And I know large ISPs who already build each server farm entirely
> on private space and expose it as a single IP address to the outside world.
> 
> Admittedly, this all comes at a cost, but it's not infeasible. If the market
> forces ISPs to deliver this, then they will.
> 
I think the costs of doing this exceed the costs of deploying IPv6.

I don't see how the loopback idea really helps conserve address space.

>>>> Equipment which does not know about IPv6
>>>> should safely ignore it like any other unknown protocol.
>>> 
>>> I don't think "should" and hope is good enough. Any across-the-board change
>>> to the service you provide has potential impact, and there are hundreds of
>>> different types of no-name routers with buggy firmware, partial or untested
>>> V6 implementations.  If and when those calls hit the callcentre, it would be
>>> wise to be able to offer a quick solution to the affected customers, rather
>>> than "sorry, your equipment doesn't work with our service, please buy a new
>>> one or go somewhere else"
>>> 
>> Again, can you cite any specific example of equipment which breaks if IPv6
>> is turned on, or, is this pure speculation on your part?
> 
> You can label it as "pure speculation" if you wish. I do have lots of
> experience of specific models of ASDL routers not working with particular
> models of DSLAMs, and of bugs in PPP implementations.  Whilst these are
> mostly layer 1 problems rather than layer 3, all of this is stuff which
> "should" just work, but doesn't.
> 
I find it very interesting that you flat out refuse to give a straight answer
to a very simple question. Do you or do you not have knowledge of any
specific example of equipment which behaves as you describe?

> So I would prefer to call it "risk identification" to suggest that if
> tomorrow I turn on IPV6CP to hundreds of different types of cheapo ADSL
> CPEs, some may break.  Some of these devices already break when they receive
> specific IPV4 packets :-)
> 
At this point, I think I can take this as a resounding "no" to my previous
question.

Is there likely to be some broken CPE out there that responds poorly to an IPCP6
packet? I suppose it's possible. It would take particularly clever coding to pay
enough attention to IPCP6 negotiation in order to have it cause you to crash while
not being able to handle IPCP6 negotiations.

Frankly, I say better to trigger it early and identify the problems so they can be solved.
You say better to avoid triggering the problems so that they aren't discovered until we
have no other choice. Obviously these are different philosophies. I'd rather know what
is broken while it is non-critical so I can fix it before it becomes critical. For those that
prefer blissful ignorance until you can no longer avoid solving a problem, Brian does,
indeed, offer a good suggestion.

> Anyway, my own opinion is irrelevant. What I'm trying to say is, it's the
> opinion of the customers which is important: in particular the home users
> and the enterprises who are primarily consumers of The Internet.
> 
Agreed. However, we have very different expectations of what those opinions
and behaviors will be when faced with a lack of IPv4 address space.

> Businesses know what they are doing: they will deploy a new technology when
> it can make them money, or save them money, at sufficiently low cost and
> risk.
> 
Businesses engage in lots of spending on things that will not make them money
or save them money. Businesses spend a great deal of money on disaster
recovery, insurance, and other business continuity measures, all the while
hoping that money is completely wasted. At this point, deployment of IPv6
really boils down to a business continuity issue rather than something that
has a cost-benefit business case to it. At some point, a sufficiently important
volume of remote destinations with which your enterprise wants to
communicate will be on IPv6 (possibly only on IPv6). Today, you have the
option of getting ready for that before it happens. If you wait until it has
already happened, you have a serious problem until you catch up.

Owen