Date: Fri, 29 Jun 2007 20:23:54 +0000
From: Paul Vixie <[EMAIL PROTECTED]>
Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
Additionally, I believe that there exist RIR policies which are
resulting
in some pressure towards implementing ULA/ULA-C -- policies which can
and
should be modified by the membership constituency of the RIRs.
on this, there is broad agreement, but the outcome has been to request
that
IANA (by way of an IETF specification) set aside some non-DFZ space so
that
RIRs can hand it out for non-DFZ use with a lower barrier to acquisition.
(*) See below at the bottom - I believe there are two contradictory
statements (unless publishing an RFC which requests that an RIR do
some particular thing, does not constitute "setting RIR policy".)
ULA-C is an interesting middle ground, but the mere existence of ULA-C
as a
concept, and as a draft that we're discussing, is a strong indicator
that
these RIR policies are a problem. And moreover, as a compromise, ULA-C
is
causing more harm than good.
obligatory disclaimer: while i'm not speaking for ARIN here, i am a member
of
ARIN's board of trustees, and i have not set ARIN's interests aside for
the
purpose of pure academic debate. and briefly, as a trustee for this
sentence
alone, let me point out that ARIN's policies are set by the community and
if
you think those policies are "a problem" you should join [EMAIL PROTECTED] and
also attend ARIN meetings and consider submitting some policy proposals to
change them.
Don't worry - those are already things I'm planning on doing.
(Thanks for the mailing list pointer - it saves me a bit of searching. ;-)).
And thanks for pointing out the ARIN meta-policy - I don't think enough
people understand that. Shouting over the wall pretty much by definition
does not constitute submitting proposals. :-)
And the reason I brought up the issue, and made the proposal, is for that
exact reason. If any of what I said made any sense, then anyone who has
reason to support those suggestions would probably be best served by also
joining in on this ARIN pariticipation activity, in a very concrete way.
I think that more "bridging the gap" between operators, policy makers,
and (<insert label for IETF here>) everyone else, needs to occur. It's bad
enough that vendors making hardware are so far behind the curve...
I also think that it's just a question of realizing that ARIN is part of
the community, part of the process, and that not participating means
not having visibility or input into things that can affect your network,
further down the road...
(end of plug for civic duties)
The requirements that I see ULA/ULA-C addressing are:
- need for IPv6 space
- need for this space to be globally unique
- need for this space to be easily acquired
- need for this space to be acquired for no cost
- need for the status of this space to be easily identifyable (DFZ or
not)
others see additional requirements. for example, the need for global
WHOIS,
global DNS, and global RPKI support for ULA space, so that even in ad-hoc
networking environments, "recourse" will be possible against malefactors.
as
a result of that requirement, a role for the regional internet registries,
and a fee level set at the cost recovery level for efficient
not-for-profit
operations, has been strongly suggested.
I don't disagree with any of the stuff that follows "as a result".
I in fact agree that there is a reasonable basis for doing so which
pretty much stands by itself, without needing any support from anyone.
Please answer me this, however (anyone, not just Paul):
- of the additional requirements listed, which of those are not available
(e.g. automatically) for PI allocations in the DFZ?
What I'm asking, of course, is this:
Is there *anything* unique to ULA that is not possible to implement with
PI allocations by RIRs?
And if so, why would it not be something to add on to every PI allocation?
(I do profess ignorance RPKI; I'm pretty sure that WHOIS and DNS are part
of the DFZ :-)).
(don't think that your own requirements aren't relevant or that your
description of them is unappreciated, but the resulting specification if
any will include a larger set of requirements and features than any one
person is likely to have, and is likely to be seen as a compromise by most
if not all of us.)
All but the last issue, are trivially manageable by relaxing the
existing
requirements in place at the RIRs, for acquiring space. [...]
as before, if you think that the existing RIR policies are wrong, there's
a
mechanism in place in every region for improving those policies. one
thing
to add at this point: IETF is not where RIR policies are made or changed.
(*) Second part of same comment from above - if the IETF publishes an RFC,
requesting that RIRs do some particular thing on a systematic basis, is
that not in effect dictating (in a passive-aggressive manner) policy to
RIRs?
I do understand the difference between requesting something of RIRs, and
telling them to do something, but fundamentally, either the RIRs do what
is asked in the RFC, or they do not. If they do not, the whole RFC is
mooted. If they do, then they have made a policy change at the behest of
the IETF.
Either way, this begs the question - how is what I was suggesting, other
than in the sense that I did not couch my suggestion as "ask nicely",
any different than ULA-C?
As far as I can tell, the main differences have to do with ULA itself,
the fact that the allocations are from a single block, and that the single
block has associated with it some rather nasty mandatory extra bits.
(Yes, I know I'm being a bit facetious - and deliberately - but the
question isn't entirely rhetorical. If the suggestion were couched the
same way as the ULA-C proposal, would it be considered acceptable from the
ARIN perspective?)
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
