Subject: Re: IPv6 RIR policy [was Re: IPv6 addresses really are scarce after all]

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 14:55:20 -0500

Thus spake "Keith Moore" <[email-masked]>
>> The RIRs do not limit the discussion of operations experience
>> to a narrow few sources, rather the the discussion is open to all
>> and an array of perspectives are offered.  The RIRs do not per
>> se discuss operations, the discussion is over policies that are
>> reflective of real world operational experience.
>
> what I meant was that users' operations are arguably as important
> as ISPs operations, and I presume that because of their
> membership the RIRs are only considering the latter.

The RIRs are definitely biased towards ISPs, because IP addressing policy is 
a core business concern to ISPs but "overhead" to other companies.  The IETF 
has more vendors but still few end users.

However, there is adequate proof the RIRs can respond to end users' concerns 
when anyone cares enough to show up: PIv6 wouldn't have happened without 
end-user operators coming out of the woodwork to support it, overwhelming 
ISP and IETF resistance.  The periodic flamefests about how to treat legacy 
space are also demonstrations of end-user input, though it seems to amount 
to no more than "leave us alone" vs "kill them all" in most cases.

>>> perhaps, but if IETF has the problem that it's not willing to
>>> assert its ownership over its own protocols, that problem is
>>> better addressed in IETF than in ARIN.
>>
>> It's not a matter of ownership but whether the engineering
>> solution is still germane to real world needs.
>
> they are separate problems.  if the recommendations we made
> are not viable, then we need to know that so we can fix it.

When you've got people in the RIRs talking about "routing around the 
failure" in reference to the IETF, that's a pretty clear indication.  I know 
the RIRs send liaisons to the IETF; does the IETF send liaisons to the RIRs 
and various NOGs?  Is anyone actually feeding information back and forth 
officially, or do we just have a few people rehashing the same arguments on 
different mailing lists?

>> IPv6 (as I first understood it) did have a business model assumed -
>> that one ISP would be all that an enterprise customer would need,
>
> I don't know anybody who assumed that.  I think it was instead
> assumed that multihomed sites could make do with multiple
> (prefixes,addresses) per (net,host) and that applications could
> somehow tolerate having multiple source and destination
> addresses, be able to pick a reasonable pair from among those
> available, and fail over to another source or destination address
> when one end or another renumbered or the connection
> failed.  (All of which I find rather dubious, but it's not the same
> thing as assuming that there would be one ISP for an enterprise.)

The operational community heard that message, deemed it not a viable 
solution, and responded by passing PIv6.  Heck, people think NAT (and we all 
know the IETF's head-in-the-sand attitude on that part of reality) with ULAs 
is more viable than multiple parallel PA assignments.

>> Okay, maybe I'm stretching the point here.  I am not sure why I
>> am bothering to post.  I guess I've become disappointed in the
>> amount of disrespect displayed in this thread.
>
> well, I'm disappointed in the amount of disrespect displayed by
> RIRs.

Perhaps that's true.  Or perhaps the RIRs are trying to get the message 
across that how they assign addresses is up to their communities, not the 
IETF.  Frankly, short of the IETF telling IANA to pull the RIRs' 
allocations, I don't see what practical authority the IETF has over address 
policy.  I also fail to see why the IETF thinks it _should_ have any 
authority over that or any other operational matters.  In my view, the IETF 
develops tools and it's up to operators to determine if/how to use them.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 19 Sep 2007 14:55:21 -0500

Thus spake "Iljitsch van Beijnum" <[email-masked]>
> On 29-aug-2007, at 22:21, Bill Manning wrote:
>> "the" RIRs are membership organizations, with members
>> consisting of the operational community.  they have to
>> try and work with whatever the IETF gives them.. and when
>> what the IETF provides is not operationaly feasable, they
>> can and will make changes so that an operational network
>> exists.
>
> In the IETF, you need rough consensus to make decisions. I'm
> not entirely sure how this works in all the RIRs, but I think at least 
> for ARIN, there is some form of voting involved.

ARIN operates on consensus as well.  The Advisory Council is tasked with 
judging consensus similar to the IETF's WG chairs, as well as ensuring the 
process is followed.  Technically the Board votes on policy changes but, 
with a few notable exceptions, they rubber-stamp the AC's recommendation.

The AC and BoT are filled by elections, which may be what you're thinking 
of.

> There are five RIRs, but the decisions they make often have
> global impact, and once one RIR has taken a course of action,
> the others often feel the need to follow.

Many folks participate in multiple RIRs and propose the same ideas in each, 
and the RIRs do observe each others' actions and determine if they're 
appropriate to adopt as well.  There's major differences, though, which are 
catalogued on the NRO web site.

> Case in point is provider independent address space for IPv6.
> For a decade, this wasn't possible because the IETF was first
> studying, and after a _lot_ of effort to get things rolling, working
> on, mechanisms to provide multihoming benefits without
> injecting a prefix into the global routing table for each multihomed
> site. Then, with something workable within reach but not quite
> finished,

The spec wasn't even finished; widespread implementation was at least a 
decade away, based on experience, and a solution was needed before IPv4 
exhaustion -- currently projected for 2012 or so.

Also, the operational community appears to have nothing but complete scorn 
for the alternatives the IETF has proposed to date.  Folks pushing the IETF 
proposals concentrated on telling the operators they were wrong instead of 
asking why they thought what they did.  As a former manager told me, "your 
customers may not always be right, but they're never wrong".

> ARIN saw fit to allow PI for IPv6 anyway, with potentially very
> harmful long-term results.

Note that part of the motivation for PIv6 was the IETF's discussion of 
ULA-C.  The other part is that there is no time left to deploy any 
alternative, no matter how great it may be, before IPv4 exhaustion happens. 
A viable multihoming solution was/is _mandatory_ for IPv6 to get deployed 
and, lacking a hammer, ARIN decided to pound their nails with a screwdriver 
rather than watch IPv6 continue to flounder.

> The IETF leadership never saw fit to say something about this
> during  the ARIN process, and the ARIN process mostly consisted
> of "I'm not worried about the future and I want my PI block".

Lots of folks came over from the IETF (I won't accuse them of being 
"leaders") to complain during ARIN's policy debates and they, with the help 
of large ISPs, managed to stall the adoption of PI for over a year.

Even the proponents of PI are worried about the future, but we are forced to 
support the lesser of two evils.  Without PI, we wouldn't have any IPv6 
routing tables to explode in the first place because IPv6 would become even 
more irrelevant than it is today.

> The RIR policy mechanisms are simply not capable of rejecting
> policy changes that benefit a subset of the community, especially
> any subset that is well-versed in RIR matters, if such a change is
> against the interest of the community at large.

I suggest you take a closer look at the debates that occur.  Many proposals 
are shot down because they're believed to harm the community; many ideas 
don't even make it to the proposal stage because of that.  Some proposals 
pass, despite obvious harm to the community, because not passing them would 
result in worse harm.

> The IETF isn't immune to this, but does a lot better than the RIRs
> because it has a technically capable leadership rather than an
> administratively capable leadership.

I'm not familiar with the organization of the other RIRs, but ARIN has two 
distinct "leadership" groups, one technical and one administrative.

> (Maybe that also explains the differences in the financial situation
> between the RIRs and the IETF...)

The RIRs charge people for output but allow free input.  The IETF charges 
for contributing but gives its output away.  The financial results are 
predictable for both, as is the community that each is responsible to: the 
IETF caters to vendors and the RIRs to operators.

S

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Sep 2007 16:35:00 -0400

>
> The RIRs are definitely biased towards ISPs, because IP addressing
> policy is a core business concern to ISPs but "overhead" to other
> companies.  The IETF has more vendors but still few end users.
>
> However, there is adequate proof the RIRs can respond to end users'
> concerns when anyone cares enough to show up: PIv6 wouldn't have
> happened without end-user operators coming out of the woodwork to
> support it, overwhelming ISP and IETF resistance.  The periodic
> flamefests about how to treat legacy space are also demonstrations of
> end-user input, though it seems to amount to no more than "leave us
> alone" vs "kill them all" in most cases.
I'm glad to hear that RIRs can respond to users' concerns, but that
doesn't change the fact that they're second-guessing an IETF decision
and that other things in the IPv6 architecture are dependent on that
design decision.
> failure" in reference to the IETF, that's a pretty clear indication.
Of what?  RIR arrogance?  No surprise there, every deliberative body
I've been involved with thinks it is superior to others.
> solution, and responded by passing PIv6.  Heck, people think NAT (and
> we all know the IETF's head-in-the-sand attitude on that part of
> reality) with ULAs is more viable than multiple parallel PA assignments.
Which head in the sand is that?  The one that thinks that NATs are
benign, or the one that thinks that they cause lots of problems?  Both
types exist in IETF. IETF is like Zaphod Beeblebrox with his heads
constantly arguing with one another from under the sand.   That's why
IETF took too long to become aware of the inherent problems associated
with NATs and too long to speak out about those problems, and has said
too little about them.  It's also why it never has developed a viable
transition path away from NAT and toward native IPv6.
>> well, I'm disappointed in the amount of disrespect displayed by RIRs.
>
> Perhaps that's true.  Or perhaps the RIRs are trying to get the
> message across that how they assign addresses is up to their
> communities, not the IETF.  Frankly, short of the IETF telling IANA to
> pull the RIRs' allocations, I don't see what practical authority the
> IETF has over address policy.  I also fail to see why the IETF thinks
> it _should_ have any authority over that or any other operational
> matters.  In my view, the IETF develops tools and it's up to operators
> to determine if/how to use them.
I think you are confusing policy with protocol design or architecture.

Keith

---

From: <[email-masked]>
Date: Thu, 20 Sep 2007 11:02:40 +0100

> I'm glad to hear that RIRs can respond to users' concerns, 
> but that doesn't change the fact that they're second-guessing 
> an IETF decision and that other things in the IPv6 
> architecture are dependent on that design decision.

Given that the IETF has not released any documentation of the decisions
in question, other than one RFC that contains deprecated material, I
think that the RIRs have every right to second-guess the IETF. If anyone
thinks that the RIRs second-guessing results in the wrong decisions,
then perhaps they will take the time to write the missing RFC with
guidance for RIRs. It wouldn't hurt to issue another RFC with guidance
for network operators, even if it covers a lot of the same ground as the
RIR guidance.

> That's why
> IETF took too long to become aware of the inherent problems 
> associated with NATs and too long to speak out about those 
> problems, and has said too little about them. 

It's that last point that I have a problem with. If supreme court judges
can't come to a consensus then at least they will explain why, by
writing a dissenting opinion. In my opinion, if there is a problem with
reaching consensus on important issues, then the IETF should pressure
both sides of the issue to write a draft explaining the problem area.

> It's also why 
> it never has developed a viable transition path away from NAT 
> and toward native IPv6.

The IETF has effectively specified that IPv6 NAT devices are the right
way to do this by not defining a standard set of functionality for an
IPv6 gateway for connecting an IPv6 network to the IPv6 Internet. By not
specifying how it is to be done, the IETF is giving carte blanche for
anyone to solve the problem in any way that they please.

--Michael Dillon