[172419] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Ars Technica on IPv4 exhaustion

daemon@ATHENA.MIT.EDU (Seth Mos)
Wed Jun 18 13:49:29 2014

X-Original-To: nanog@nanog.org
From: Seth Mos <seth.mos@dds.nl>
In-Reply-To: <CAAAY2agLydjvWJb1jtLbKSGSfVRVKHH-g5-JHHR_ZgGuC7Tvig@mail.gmail.com>
Date: Wed, 18 Jun 2014 19:45:30 +0200
To: Martin Geddes <mail@martingeddes.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces@nanog.org


Op 18 jun. 2014, om 11:41 heeft Martin Geddes <mail@martingeddes.com> =
het volgende geschreven:

> "IPv6 will never become the defacto standard until the vast majority =
of
> users have access to IPv6 connectivity."
>=20
> It may never become the defacto standard, period. Nearly 20 years to =
reach
> 2% penetration is a strong hint that the costs outweigh the benefits.

To be fair, it is only now that there is considerable leverage to =
actually use IPv6 outside of a academic scope. Our company is ready now, =
and it=92s just a commercial retailer. I know we are way ahead of the =
curve but I didn=92t find it all that hard.

I see a lot of people crying foul, still, but IPv6 capable equipment is =
readily available now, and, it is up to you if you find it worthwhile to =
purchase. The worldwide IPv6 transit network is complete and most ISPs =
can actually deliver on IPv6 if you push them for it and don=92t let =
them ship you off with =84we can=92t do it yet=94.

As such we=92ve had IPv6 at work since 2012, and we got to talk to =
engineers and it wasn=92t really that much of a problem. Also, the free =
BGP tunnel from HE.net really is a lifesaver in getting at least backup =
peering in place, and that worked fine for over a year.

> IP's global addressing system is broken from the outset. See John =
Day's
> presentation "Surviving Networking=92s Dark Ages - or How in the Hell =
Do You
> Lose a Layer!?"
> <http://irati.eu/wp-content/uploads/2013/01/1-LostLayer130123.pdf> =
(or,
> indeed, lots of them at once.)

I don=92t know, 64 bits for the networks, and 64 bits for the hosts =
seems fine, although to be fair, a 96/32 split could have worked too, =
more about networks and aggregated routes, less about hosts. It=92s also =
really good that there is a =84absolute split=94 at 64 bits to designate =
the network prefix part. That makes network identifying a lot easier. I =
suppose that is where the shorter network prefix is coming from, it=92s =
easier to remember.

> It's really all about scopes, not layers - the TCP/IP architecture is
> divided up the wrong way, and it will never be fixed. It's an escaped =
1970s
> lab experiment that was able to extract the statistical multiplexing =
gain
> faster than rivals, but on a performance and security "buy now, pay =
later"
> basis.

I like that IPv6 is close enough to IPv4 that I can just run with it. =
That=92s not a drawback. If you understand classless subnetting you can =
work with Ipv6.=20

> May all your intentional semantics become operational,
> Martin

I didn=92t find it all that hard to become operational. Not everything I =
have at work does IPv6, but that=92s not really a requirement, is it?

I don=92t care enough for backwards compatability with IPv4, actually, =
I=92m really glad it isn=92t so failure states are much easier to =
diagnose. I can see how IPv4.2 SP2 would have subtle issues with IPv4.3 =
SP1, but there is a hot fix for that, but not for your model. SOL.

Not very different if I must say.

Cheers,
Seth



>=20
> On 17 June 2014 23:12, Andrew Fried <andrew.fried@gmail.com> wrote:
>=20
>> IPv6 will never become the defacto standard until the vast majority =
of
>> users have access to IPv6 connectivity.
>>=20
>> Everything I have at the colo is dual stacked, but I can't reach my =
own
>> systems via IPv6 because my business class Verizon Fios connection is
>> IPv4 *only*.  Yes, Comcast is in the process of rolling out IPv6, but =
my
>> Comcast circuit in Washington DC is IPv4 only.  And I'd suspect that
>> everyone with Time Warner, AT&T, Cox, etc are all in the same boat.
>>=20
>> Whether the reason for the lack of IPv6 deployment is laziness or an
>> intentional omission on the part of large ISPs to protect their =
income
>> from leasing IPv4 addresses doesn't matter to the vast majority of =
the
>> end users;  they simply can't access IPv6 via IPv4 only networks,
>> without using some kludgy, complicated tunneling protocols.
>>=20
>> Andy
>>=20
>> --
>> Andrew Fried
>> andrew.fried@gmail.com
>>=20
>> On 6/17/14, 5:48 PM, Jared Mauch wrote:
>>>=20
>>> On Jun 17, 2014, at 5:41 PM, Lee Howard <Lee@asgard.org> wrote:
>>>=20
>>>>=20
>>>>=20
>>>> On 6/17/14 4:20 PM, "Jay Ashworth" <jra@baylink.com> wrote:
>>>>=20
>>>>> Here's what the general public is hearing:
>>>>=20
>>>> But only while they still have IPv4 addresses:
>>>> ~$ dig AAAA arstechnica.com +short
>>>> ~$
>>>>=20
>>>>=20
>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>> =
http://arstechnica.com/information-technology/2014/06/with-the-americas-ru=

>>>>> nning-out-of-ipv4-its-official-the-internet-is-full/
>>>>=20
>>>>=20
>>>> Can't tech news sites *please* run dual stack while they're =
spouting
>>>> end-of-IPv4 stories?
>>>=20
>>> <wishful thinking=3Don>
>>>=20
>>> I would love to see a few more properties do IPv6 by default, such =
as
>> ARS, Twitter and a few others.  After posting some links and being a =
log
>> stalker last night the first 3 hits from non-bots were from users on =
IPv6
>> enabled networks.
>>>=20
>>> It does ring a bit hollow that these sites haven't gotten there when
>> others (Google, Facebook) have already shown you can publish AAAA =
records
>> with no adverse public impact.  Making IPv6 available by default for =
users
>> would be an excellent step.  People like AT&T who control the =
'attwifi'
>> ssid could do NAT66 at their sites and provide similar service to the
>> masses.  With chains like Hilton, McDonalds, etc.. all having this
>> available, it would push IPv6 very far almost immediately with no =
adverse
>> impact compared to users IPv4 experience.
>>>=20
>>> - Jared
>>>=20
>>=20


home help back first fref pref prev next nref lref last post