Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt

From: [email-masked]
Date: Fri, 29 Jun 2007 17:22:24 -0400 (EDT)

> Date: Fri, 29 Jun 2007 20:23:54 +0000
> From: Paul Vixie <[email-masked]>
> Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
> To: [email-masked]
> Message-ID: <[email-masked]>
>
>> 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-masked] 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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 29 Jun 2007 14:43:07 -0700

Brian,

I won't try to reply inline, but let me address your questions more 
generally:

With regards to the relationship between RFCs and RIR policy, my 
understanding is that RFCs more or less direct IANA how to go about 
giving out space to the RIRs.  However, each RIR can decide for itself 
whether it wants to participate in the allocation of a certain type of 
IP space.  Right now, not all RIRs support IPv6 PI space, and it would 
similarly require policy for each RIR to begin assigning or allocating 
ULA-C space.  In addition, this is not just a binary decision: an RIR 
could decide it wanted to do direct ULA-C assignments, and/or it could 
decide to do ULA-C allocations to LIRs.  The RFC sets general direction, 
but leaves it up to the RIRs (and to some extent even to IANA) how the 
space is actually given out.

With regards to the oft-repeated question of "Is there *anything* unique 
to ULA that is not possible to implement with
PI allocations by RIRs?": In theory, no, but in practice, yes.  ("In 
theory, theory and practice are the same, but in practice, they're 
not.")  If/when it becomes feasible for RIRs to give out PI space to 
anyone who asks, without concern over whether that space will end up in 
the routing tables of every full-BGP-feed router on the planet, then PI 
would meet the same need as ULA-C.  Until then, ULA-C allows us to 
allocate space to networks who don't need to announce it to their 
transit providers, but who would still like to be able to privately 
interconnect with other networks using their own unique, registered IP 
space.

Hope that clarifies things a bit, and I look forward to seeing you on PPML.

-Scott

---

From: Roger Jorgensen <[email-masked]>
Date: Fri, 29 Jun 2007 23:57:42 +0200 (CEST)

> Is there *anything* unique to ULA that is not possible to implement with

not really no. Except that real end-users like your brother can get ULA-C 
cheap but maybe have to pay a bit more for PI.

> And if so, why would it not be something to add on to every PI allocation?

you mean automaticly add ULA-C to each PI allocation? Sure why not, but 
that will be upto the RIRs to decide as I see it.

-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - IPv6 is The Key!
-------------------------------------------------------

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 29 Jun 2007 15:05:00 -0700

Roger Jorgensen wrote:
> not really no. Except that real end-users like your brother can get 
> ULA-C cheap but maybe have to pay a bit more for PI.

ULA-C and PI space will likely both cost about the same, and your 
brother could likely afford either.  The issue isn't so much dollar cost 
as availability: your brother likely doesn't qualify for PI space 
(unless he can justify efficient use of a /22), but he could get ULA-C 
just by asking.

-Scott

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 29 Jun 2007 23:19:55 +0100

> (unless he can justify efficient use of a /22), but he could get ULA-C

Wow, a /22 IPv6 space, that is a big chunk. But I assume you mean /22
IPv4. What has IPv4 to do with IPv6 and moreover why is that ARIN policy
 being forced upon the IETF thus leading to ULA-C and then leading to
heavily hinting ARIN to provide ULA-C as a way out.

Clearly ULA-C is just "cheap address space", nothing more nothing less.
And the sole reason for a possible existence seems to be that the
policies in RIR land do not allow everybody to get address space the way
they want to. Instead of changing the RIR policies, ULA-C gets invented.

Which is also what you write in the 2 emails before this one, but in
between the lines.

The RIR community effectively blocks people from getting address space
on the premise that "but that costs routing slots", even though the
minimum allocation is /48 either way, and then on top of that basing
that decision on IPv4 address space usage, wow.

I think that ULA-C is a really really bad idea because of this.

But I'll let other people figure that out, I've clearly spoken my mind
about this already. I do hope that other people see this too.

Greets,
 Jeroen

---

From: Roger Jorgensen <[email-masked]>
Date: Sat, 30 Jun 2007 00:23:41 +0200 (CEST)

On Fri, 29 Jun 2007, Jeroen Massar wrote:
<snip>
> about this already. I do hope that other people see this too.

yes it is a bad idea, but for the time being, it seems to be the 
right thing. Might even be necesary for IPv6 deployment to. For us, where 
I work, ULA-C is great, it give us everything we want. PI or/and PA will 
do the same job but ULA-C is easier to use, nothing else.

--

---

From: bill fumerola <[email-masked]>
Date: Fri, 29 Jun 2007 16:14:08 -0700

> Is there *anything* unique to ULA that is not possible to implement with

AfriNIC has said they will recind PI address space that is not "announced"
within a year. you may interpret "announce" as you wish. i assume they
mean in the DFZ.

which means PI space from AfriNIC is unusable for this purpose.

-- bill

ps. i sent a lengthy mail to this list detailing this but nobody replied.
    i hope the point that just because RIRs now have PI policies that
    may allow for PI space that you don't announce, that may not always
    be the case. AfriNIC is already a counter-example. their policy may
    change too.

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 29 Jun 2007 16:36:15 -0700

Jeroen Massar wrote:
> IPv4.  What has IPv4 to do with IPv6?

Yes, I was referring to a /22 of IPv4 space.  Current ARIN policy 
requires that, in order to get IPv6 PI space, you meet the same 
qualifications as for IPv4 PI space.  (You needn't actually get the IPv4 
space, but that was the least controversial method of justification 
available, which avoids going down the controversial rat-hole of 
justifying by "sites", "nodes", or "subnets" and specifying HD ratios 
within an end-user's network.)
>  and moreover why is that ARIN policy

I don't think there's any forcing going on.  See below.

> they want to. Instead of changing the RIR policies, ULA-C gets invented.

Do you have a proposed change to RIR policies?  If so, I invite you to 
make a policy proposal.  I also invite you to read the archives of the 
discussion surrounding previous similar policy proposals.

> that decision on IPv4 address space usage, wow.

I don't know about you, but I help run a network that provides those 
routing slots, and doing so costs real money.  Right now we're in the 
process of upgrading a large number of routers, at significant cost, 
simply to provide enough routing slots to support the growth in the BGP 
table. 

The RIRs currently require small networks to get provider aggregatable 
(PA) space from their provider(s).  This ensures that any more-specific 
routes originated from such space can be safely filtered, while 
maintaining reachability via the provider's aggregate.  PI space cannot 
be filtered this way, so there is a higher bar for getting such space.  
The height of that bar can be adjusted (as was recently done for IPv4 by 
changing from a /19 to a /22 for multihomed networks.) In fact, the IETF 
originally specified that all IPv6 space should be PA, leading to fears 
that ULA-C space would become the only de facto PI space.  With recent 
action by the RIRs to create IPv6 PI space, those fears have been mostly 
alleviated.

> I think that ULA-C is a really really bad idea because of this.

Perhaps.  But just as "Democracy is the worst form of government there 
is, except for all the others we've tried", I think ULA-C is better than 
what's available now, and more practical in the near term than a 
PI-for-everyone utopia.

The fact that IPv6 PI space exists at all is due to the action of 
individuals working through the RIR public policy process to create it.  
Some of the same individuals, recognizing they've pushed as far as they 
can toward liberalizing PI for now, would like to create additional 
flexibility for small networks to use IPv6 in a way that suits their 
needs.  In order to avoid creating an IPv6 "swamp", those individuals 
have asked the IETF to standardize a new form of registered private IP 
space out of a single common global netblock, and allow the RIRs to 
begin allocating/assigning that space to registrants.  Their attempts to 
do so are being met with cries of "why don't you just liberalize PI."  
Do you see the irony here?

-Scott

---

From: Paul Vixie <[email-masked]>
Date: Sat, 30 Jun 2007 01:30:24 +0000

> From: bill fumerola <[email-masked]>
> > 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?
> 
> within a year. you may interpret "announce" as you wish. i assume they mean
> in the DFZ.
> 

more to the point, we're expecting vast numbers of ULA-C prefixes to be
allocated -- tens of thousands -- hundreds of thousands? -- millions?? --
and the RIR community is uncomfortable with having to upgrade their
routers to be able to handle that number of prefixes.  therefore they're
pushing for FC00::/7 or some other fingerprint that makes them un-DFZ-able,
and in exchange, they seem to be comfortable with a much lower barrier to
acquisition for this type of prefix.

---

From: Leo Vegoda <[email-masked]>
Date: Sat, 30 Jun 2007 16:22:06 -0400

On 29 Jun 2007, at 7:36pm, Scott Leibrand wrote:

[...]

> The RIRs currently require small networks to get provider  
> aggregatable (PA) space from their provider(s).

This just isn't true. Both APNIC and the RIPE NCC will assign  
prefixes longer than an IPv4 /24. APNIC even document the fact quite  
nicely where they say "There is no minimum assignment size for  
portable assignments made under these terms".

http://www.apnic.net/docs/policy/add-manage-policy.html#11.1

Over the last two years the RIPE NCC has assigned about 2800 prefixes  
longer than /22 and APNIC have made over 200. It's all there in the  
statistics files that the RIRs publish every day on their FTP sites.

[...]

> Perhaps.  But just as "Democracy is the worst form of government  
> there is, except for all the others we've tried", I think ULA-C is  
> better than what's available now, and more practical in the near  
> term than a PI-for-everyone utopia.
>
> individuals working through the RIR public policy process to create  
> it.  Some of the same individuals, recognizing they've pushed as  
> far as they can toward liberalizing PI for now, would like to  
> create additional flexibility for small networks to use IPv6 in a  
> way that suits their needs.  In order to avoid creating an IPv6  
> "swamp", those individuals have asked the IETF to standardize a new  
> form of registered private IP space out of a single common global  
> netblock, and allow the RIRs to begin allocating/assigning that  
> space to registrants.  Their attempts to do so are being met with  
> cries of "why don't you just liberalize PI."  Do you see the irony  
> here?

I can see that people will grab some ULA-C space if it becomes  
available. But I've not yet read a good definition of where it won't  
be routable while I've read at least one statement confirming that  
ULA-C routes would be accepted if they were offered.

The core problem seems to be a very soft definition of "local". If  
that's firmed up then there might be a way to convince people that  
ULA-C can be restricted to "local" networks and not be used as a way  
of getting cheaper PI space, or a way of getting PI space where the  
RIR doesn't have a policy supporting its assignment.

Regards,

Leo

---

From: Paul Vixie <[email-masked]>
Date: Sat, 30 Jun 2007 21:56:54 +0000

From: Leo Vegoda <[email-masked]>:
> 
> The core problem seems to be a very soft definition of "local". If  that's
> firmed up then there might be a way to convince people that  ULA-C can be
> restricted to "local" networks and not be used as a way  of getting cheaper
> PI space, or a way of getting PI space where the  RIR doesn't have a policy
> supporting its assignment.

i don't see a lot of folks who need to be convinced, mostly just people who
are concerned that a lot of other folks aren't convinced.  the number of
people who have actually said that they themselves aren't convinced is small.

but more importantly, we can define "local" any way we want, and we probably
will, for the purpose of getting this specification written.  but there's no
recourse at all by part A if parties B and C decide to "violate" the "local"
definition.  (nor is there any harm to party A so literally nobody should
care about this, yet a lot of folks are terribly concerned about it anyway,
i think heinlein called this the "aunt millie syndrome".)  so, yes, by all
means, let's find a comforting definition for "local", because while it won't
matter all in operational practice, it will make a big difference in the
general acceptance, dare i say consensus, of the resulting specification.

for the record, i am comfortable with the definition of "local" that was
quoted here a few weeks back, which was more or less "same autonomous system".
(but then, i'd be comfortable with a lot of other definitions, so, let fly!)