In an IPv6 future, how will you solve IPv4 connectivity?

[Ted Mittelstaedt]

On 10/11/2010 11:00 AM, Cameron Byrne wrote:
>>
>> I can make as many IPv4 addresses as I want using private
>> IPv4.  Your statement assumes that a private IPv4 number is not usable.
>> This is obviously wrong.
>>
>
> Thanks for correcting me.  Let me know how that goes for you.
>

OK enough with the sarcasm.  Why exactly do you think that ISP's
issuing private IPv4 to customers will not work?  We aren't talking
issuing IPv4 to all customers - just the ones that don't need to
be reachable.  Such as Ma and Pa Kettle who only use e-mail and
surf the web occasionally.  That should generate enough public IPv4
for us to get us past the transition period.  And I daresay, many
other ISPs.

And no, I don't consider cell providers to be ISPs.  I think cell 
providers like to gussy themselves up as ISP's but until Ma and Pa
Kettle can slap down money for a cell phone and tether it to their 
laptop without paying some insane by-the-minute fee, or dealing with a 
data cap, they are just pretending to be ISPs.  At least, in the US
at any rate.  No offense intended, just a clarification of terms here.
What works and is going to work for cell carriers isn't going to be
applicable to ISPs.

>
>>   The point of IPv6-only is that IPv4 is
>>>
>>> exhausted.  Given that dual-stack has not seamlessly transitioned us
>>> to IPv6 as it was envisioned 10 years ago, demand for IPv4 will soon
>>> exceed supply. Hence, IPv6-only solutions.
>>>
>>
>> My point is an ISP that is "out" of public IPv4 must offer some IPv4
>> solution.  That will be private IPv4.  I think this is a given.
>>
>
> Nope, not a given.  But, you can do that. Others will do something
> else.   My advice is that you accurately count how much money you keep
> plowing into IPv4.
>

Most of the smaller ISPs out there have much cheaper labor costs for
internal projects than they have for buying equipment.  I can build
NAT44 gateways and run private numbering for the cost of a few cheap
BSD/Linux servers, on implementations that are solid, tested, and have 
been in use for years.

Or, I can use something like the Ecdysis project to do the same thing
on cheap BSD/Linux server with NAT64 except only about 5 other people in 
the world are doing it, and God knows how stable the thing would be.
(OK that's a bit of exaggeration, but I think you get the idea)

Or, I can spend $10K on some Cisco or Juniper NAT64 gateway.

Now go figure what I'm going to do.

>> The only question is how to get that private IPv4 access to the
>> public IPv4.  You can use a proxy, yes.  But NAT does everything a
>> proxy will do plus a lot more.  Thus the proxy is redundant, it costs
>> extra money for basically nothing.
>>
>>>> I also see little point in fielding a proxy that allows IPv4-only to
>>>> surf the IPv6 Internet.  Fielding a proxy like this costs us money
>>>> and it's a given that the major content providers will be dual stacked
>>>> for many years yet.
>>>
>>> My customers, cell phone consumers, are generally not interested in
>>> IPv4 or IPv6 or Dual-stack.   They just want it to work.  If I do not
>>> have the IPv4 addresses (public, private, bogon), the service will not
>>> work.
>>>
>>
>> How would you not have sufficient IPv4 private?  Once you throw out the
>> assumption that all cell phone hosts in your network must have direct
>> IPv4 connectivity to all other hosts in your network, (which is what
>> the use of private numbers essentially gives you) if you run out of
>> 10.x.x.x numbers in a subnet, you just create another 10.x.x.x subnet and
>> start over.
>>
>
> Been there, done that.  But, unfortunately it's not acceptable to not
> have unique numbers since the future of mobile telephony is IMS SIP, i
> presume you are in a different corner of the 'net.  In 4G, there is no
> other solution for voice.  And yes, dual-stack costs more.  In some
> cases, it literally costs 2x.  For example, existing 3GPP mobile
> networks require unique attachments for IPv4 and IPv6, and i pay by
> attachment to the equipment vendor.
>
> Verizon Wireless has 40 instances of 10.0.0.0/8 in their network
> today.  Yes, they can go to 80 instances or 80,000 instances, but at
> what point do we say IPv4 is "run out"? There is a lot of overhead and
> hack that go into administering a very large scale network with
> duplicate address space.
>
>   In reality, very near the majority of my user's traffic goes to
> Google and Facebook.  They both have IPv6 services today.   So, if i
> deploy IPv6-only handsets today, for those handsets, very near the
> majority of their ISP traffic will be IPv6 end to end native, no NAT
> needed for Google and Facebook.  Today on IPv4, 100% NAT is needed.
>


If the cell providers like Verizon had spent just a bit more money years
ago and deployed IPv6 networks, nobody would be hand-wringing today. 
It's not like they didn't know this was coming.

You say a statement like "if i deploy IPv6-only handsets today".  Are 
you going to pay for those phones?  You won't deploy squat
unless you can convince your customers to buy new phones.  That's your
and every cell carriers real problem.  Sure, IPv6 is a solution - they
could deploy IPv6 phones.  But they can't do it unless they convince
people to buy them.  And that's not easy during the Great Recession.

> So in summary:
>
> 1.  DS costs more for me, maybe not for you
>
> 2. There is A LOT of content on IPv6 today, and with just a few more
> big players (Akamai and Yahoo are in the works), IPv4-only sites will
> be the long tail.  IPv6 content means NAT64 is less expensive and more
> reliable than NAT44 solutions.
>

Until something breaks, and then it is blame game time.  Our highest
technical support costs these days are in supporting OTHER people's
networks, or more specifically helping our customers figure out what
is wrong when some other ISP's network is doing something stupid.

In those cases when I discover it's the other guy's fault then I
have to get my customer to push his corespondent to push their ISP
to fix the problem.  Any excuse the other ISP can use to push the
blame back to me is used.  I'm sure that these networks will be
using "we don't support IPv6 it's still experimental" for this kind of 
excuse for many years.

> 3.  There will be IPv6-only hosts that will reach the internet via
> NAT64, many people do it today and it works well.
>

If you do not have control over the network stack they are using to 
access the Internet then it's a different story.  Cell carriers do,
they control the software that the IP stack the user is using runs.
ISPs have to work around what the customer has running and how badly
the customer has f'd it up.

Ted

>
>
>>> I believe there are 2 separate problems one is in the access network
>>> and one is in the content network.
>>>
>>> If the access network is growing (anything mobile, devices in the home
>>> like DVR ...), they need to move to IPv6 as soon as possible since
>>> IPv4 is not growing.  It is a simple business continuity story.  If
>>> the access network is not growing, the business case is less urgent,
>>> but a good idea.
>>>
>>> For content providers, they NEED to be dual stack to reach all their
>>> possible eyeballs.  Once again, it is a simple business continuity
>>> story.  Without dual-stack (from a service perspective), you will not
>>> have the best method of reaching all your customers.
>>>
>>
>> Yes I agree those problems exist but I think there is too much emphasis
>> on the notion that legacy IPv4-only hosts will want to access the IPv6
>> Internet.  By the time that content providers out there are IPv6-only,
>> Windows XP will be a distant memory, and most CPE devices that are IPv4-only
>> will be close to 2 decades old  The legacy IPv4 hosts at that
>> time will be in such a minority that the industry can cease catering to
>> them.  They can run their own proxy servers if they want their 50-year-old
>> VAX to access "the Internet"
>>
>> Ted
>>
>>> Cameron
>>>
>>
>>
>