[[members-discuss] [ncc-announce] RIPE NCC Position On The ITU IPv6 Group]

Mailman List Mirror (Read Only)
1

Date: Sat, 27 Feb 2010 12:04:12 +0800
From: Phil Regnauld <regnauld@nsrc.org>

Nick Hilliard (nick) writes:
>
> And the politicians. Yes, they will erupt in hitherto unseen
> outbursts of self-righteous indignation at the stupid internet
> engineers who let this problem happen in the first place and who
> made no provision whatsoever for viable alternatives,

  Um, not to be the party pooper of your fire-and-brimstone scenario,
  but IPv6 deployment has taken quite a bit longer than expected.

  I'm not saying that political incentives (carrot & stick) or government
  regulations in the line of "implement IPv6 before X/Y or else..." have
  had any effect, except maybe in Japan: look how long it took for the
  EU commission to jump on the bandwagon, for instance (or for that matter,
  how long it took any government to take IP seriously).
  
  But if was asked why IPv6 hasn't been deployed earlier, I'd be hard
  pressed to come up with a simple answer. "It wasn't ready"
  is probably not considered good enough for an elected official.

<rant>
I'm sorry, but some people are spending too much time denying
history. IPv6 has been largely ready for YEARS. Less than five years ago
a lot of engineers were declaring IPv6 dead and telling people that
double and triple NAT was the way of the future. It's only been over the
past two years that a clear majority of the networks seemed to agree
that IPv6 was the way out of the mess. (I know some are still in
denial.)

Among the mistakes made was the abandonment of NAT-PT as a transition
mechanism. The BEHAVE working group has resurrected it and I still have
hope of a decent system, but it has not happened as of today and we need
it yesterday.

Because so many network engineers or their managers decided that IPv6
was either not going to happen or was too far down the line to worry
about, vendors got a clear message that there was no need to spend
development money adding IPv6 support to products or implement it for
their services.

I won't go into the mistakes made by the IETF because they were doing
something very un-IETF under tremendous time pressure. The standards were
developed on paper with almost no working code. This was because the
IETF assumed that we would run out of IPv4 long ago since the basics of
IPv6 pre-date CIDR. They pre-date NAT. Yes, IPv6 has been around THAT
long.

At leat one network was running IPv6 on its network, available to users
for testing for over 15 years ago. It's been a production service for
years.

Let's face reality. We have met the enemy and he is us. (Apologies to
Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for
years after it was available. Almost all operating systems have been
IPv6 capable for at least five years and most much longer. Most routers
have been IPv6 ready for even longer. But we didn't move IPv6 into
services nor offer it to customers. As a result, it just sat there. Code
was not exercised and bugs were not found. Reasonable transition
mechanisms are nowhere to be seen, and the cost of fixing this (or
working around it) has grown to frightening proportions.
</rant>

There is a lot of blame we can spread around, but take moment and look
in a mirror while you parcel it out. I think we are more responsible for
the situation than anyone else.

2

Say it brother!

The fact of the matter is that by and large, the operator community not
only ignored IPv6 but many poo-poo'ed it and diminished any amount of
support for it from the small contingent of those who were willing to
progress its deployment. In the past there were claims that it was
immature and flawed but for the most part no one really wanted to commit
themselves to putting up or shutting up.

Meanwhile clued and semi-clued users watching from sidelines could do
nothing but play in a vacuum and yell in frustration as their providers
ignore them as well. I speaking as a demoralised user personally gave
up begging my provider for IPv6 connectivity. Yes, there's always
tunnels but that's not the answer for real deployment. Remember how
well tunnels worked out for multicast?

As a result, we are in a situation today where we are now scrambling to
do the things that should have evolved naturally. Worse than stale code
is stale procedures and the lack of long-term growth and embracement.

What this means is that while we once could have taken the chance and
deployed a less than perfect technology, gotten early adopters and
slowly progressed mass-adoption, we are now in a position that we have
to undergo a crash-course in training and operational procedures.
Beyond that, the user community will need to be educated and even more
effort will need to be made in order to make things user-friendly.

And because of the heightened need for more modern features as well as
security, I might argue that we are relatively less prepared in our IPv6
development from a software standpoint than during the infancy of the
protocol.

It is often much easier for everyone involved if you slowly raise the
bar rather than suddenly springing an Olympic level high-jump upon them.

3

I'm sorry, but some people are spending too much time denying
history. IPv6 has been largely ready for YEARS. Less than five years ago
a lot of engineers were declaring IPv6 dead and telling people that
double and triple NAT was the way of the future. It's only been over the
past two years that a clear majority of the networks seemed to agree
that IPv6 was the way out of the mess. (I know some are still in
denial.)

Certainly, ipv6 is as popular in some quarters as global warming at a GOP
convention.

Let's face reality. We have met the enemy and he is us. (Apologies to
Walt Kelly.) We, the network engineers simply kept ignoring IPv6 for
years after it was available.

It's not just the engineers. The problem is completely systemic to our
culture. We live in a world where the planning window is the next
financial quarter. If something doesn't make money during that period,
then most organisations won't bother doing anything with it.

And while some bits of ipv6 have been "ready" for years (icmp ping, for
example), lots of other things haven't. There is a huge feature disparity
in most networking equipment that I use. I still can't monitor my ipv6 BGP
sessions because bgp4-mib2 hasn't been standardised. When I try to
configure my firewall using the point-n-drool GUI which most people will
use, it displays a friendly dialog box saying that my ipv6 configuration
commands have been ignored. How many enterprise network admins are going
to bother configuring ipv6 if their only configuration interface doesn't
support it?

The RA vs DHCPv6 debacle lingers on (and anyone who tries to claim that
this isn't a debacle is living in cuckoo land), making what was supposed to
be the simplest, easiest part of ipv6 a configuration mess involving
multiple protocols.

But the root cause is that proper ipv6 deployment costs money, and while
lots of us have ipv6 deployed in our core, that's probably the easiest and
cheapest part of our organisations to deploy it. After that, there's still
provisioning systems, support/troubleshooting, multiple protocol stack
security issues, and so forth. This is where the real deployment costs
time and resources.

Nick

4

I'm sorry, but some people are spending too much time denying
history. IPv6 has been largely ready for YEARS. Less than five years ago
a lot of engineers were declaring IPv6 dead and telling people that
double and triple NAT was the way of the future. It's only been over the
past two years that a clear majority of the networks seemed to agree
that IPv6 was the way out of the mess. (I know some are still in
denial.)

http://www.hactrn.net/sra/vorlons

a decade old, but still rings true

randy

5

What NANOG contributors, if any, are invited by a government, to join
their national delegation to the initial meeting of the ITU's IPv6
Group in Geneva next week?

6

It's a nice essay, but the author seems to have overlooked the contingent fact that he's a member of a species that is actually supported by the ecosystem that he's writing about. The Sahara Desert is an ecosystem too, as is the surface of the moon.

Of course, the Internet is really only like an ecosystem in the way that Tokyo and Los Angeles and Lagos are individually like ecosystems. If you think you'd be indifferent to the question of which of these places you'd prefer to live in, and prefer your children to live in -- even knowing that there are no suburbs or country retreats to escape to, anywhere -- then I guess it really is just a philosophical question.

TV

7

None.

8

You can speak for yourself :slight_smile:

Some of us are watching the lists on the appropriate mailing list(s) hosted by the US State Department. I know I facilitated a few people joining them.

- Jared

9

There were a few representatives of the Internet community at the
meeting. All five RIRs were represented, as was ISOC. The notable
absence was ICANN. Of course, this sample is by no means
representative of the entire community, but it's more than "None."

10

Well, actually, ICANN was in Geneva specifically for the meeting, but we weren't allowed into the room. Quite annoying, actually.

Regards,
-drc

11

Eric asked who was invited by a government to join a delegation. I
think that the ITU invited the RIR's.

Jared. Mailing lists don't count :slight_smile:

Best,

Marty

12

When the invitation goes out to the list membership saying "Who is going to be at X and needs creds/whatnot" that certainly counts.

Sorry you don't see it that way.

- Jared

13

Yep, I would agree that the "Internet technical community," as they like
to pigeonhole us, were well-represented at the meeting, and in the process
running up to the meeting.

                                -Bill

14

I'm not disagreeing. But see DRC's comment.

Best,

-M<

15

That's odd. I was invited, by the US, but I'd scheduled CORE's
technical meeting in Dortmund the following week, and there is only so
much away time I can schedule while my wife is a 1L at Cornell Law, so
I sent my regrets.

The utility of going, as part of the US ISP delegation, and being
excluded from even observing, seems odd.

Anyway, the point of my question is how much clue is available when
and where policy is made, visibly in the neighborhood of zero through
ICANN's (and this is not drcs' fault, far from it) vehicle for ISP
participation in policy making. So what is it in the ITU playpen? The
value appears to be in the same range. I could be completely mistaken,
hence the question.

The short form of my contribution to the issues discussion is that
iso3166 in the IANA root solved a scaling problem (epoch==Jon Postel),
but left stateless peoples waiting for DNS Godot. A CIR model has the
same issue for v6 allocation, leaving the same peoples waiting for a
single v6 block Godot. Agreement is not mandatory.

Eric

16

Why isn't this on YouTube?

j

17

You'd have to ask the ITU secretariat. I'd note that they do audiocast meetings such as this, however you have to have a "TIES" account to gain access to it. Not sure how one would go about getting a TIES account.

Regards,
-drc

18

I'm talking the ITU refusing ICANN entrance at the door..

19

Joly,

It is just another 501(c)(3) incorporated in California. Just as the
ITU is just another treaty organization. The basis for cooperation has
to be mutual interest, not mere assertion of presence, and getting to
maybe after a long, and not very cooperative history, isn't
necessarily YouTube material.

FWIW, CORE was formed at the ITU, and nominally our relationship with
the ITU is slightly less awful than ... any other lobbyist or actor in
the room when Asst. Sec. Gomez was introduced to the community last
Winter. At least, I said so and no one bothered to point out that I
was either wrong or an idiot. Both those things could yet happen.

Eric

20

$20,000/year to the ITU secretariat to become a sector member.

Owen