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

From: "TJ" <[email-masked]>
Date: Sun, 1 Jul 2007 09:14:09 -0400

"Clearly ULA-C is just "cheap address space", nothing more nothing less."
Well, yes and no.  Mostly yes.  It is also a readily identifiable block of
said (cheap) addresses, with some operational differences from normal
(globally routable) addresses.

I, for one, have no problem at all with ULA and ULA-C, in principle.
Private address space, for people/environments, etc. to use however they
want seems like a dandy idea.
	... and will present a familiar feel to those who do similar in IPv4
w/ RFC1918 addresses.

The catch that arises, IMHO, is WRT the DNS resolvability of these addresses
(#3 & #4, below).

I am mostly neutral here:
* While I see the value of having them resolve, I understand the (real |
perceived) operational impacts thereof.
* I also see the value in not having global resolution of non-globally
reachable hosts.

(I say mostly neutral because I am leaning towards the "make them
resolvable" side of the fence, having worked in lots of IPv4 VPN situations
where the destination addresses where RFC1918 (not globally reachable) and
the (forward) resolving of hosts was a royal PITA I can see lots of benefit
from having these resolve "automagically" (FWIW, exactly the situation
mentioned in the draft) ... basically, a difference between being able to
reach the node and knowing the address(es) I should be trying to reach it at
... )
(I also see the value in this address range being obviously special (i.e. -
from a single, well-known prefix, as this greatly simplifies filtering)

I guess what I am getting at ... in my mind, it boils down to:
1) Is there a reason to not support ULA/ULA-C, sans DNS?
	(Keeping in line with "tell me what I can do, and how I can do it -
not what I can't do" ... or, maybe even " Be conservative in what you send
and liberal in what you accept.")

2) For ULA-C, in order for it to work we need a registrar or some sort ...
maybe IANA, maybe the RIRs, maybe a robot.

3) Is there a major operational challenge to allowing forward DNS resolution
of ULA-C addresses?  
	("It's my zone, and I'll put whatever entries I want in there")

4) WRT reverse DNS ... my thought would be to drop this.  If it becomes
necessary for you to reverse-lookup the addresses you are talking to over
this private network connection then maybe it is time to manage that
internally ... or revisit this issue in the future, if it becomes that
prevalent?

5) Note that this does not preclude, nor prevent, PI (micro)allocations or
any other RIR-based allocation scheme/effort ... and that specifically,
these ULA-C addresses are not meant to be globally routable (nor to be seen
as "cheap PI address space").

... just more thoughts ... 
/TJ

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 15:47:50 -0500

Thus spake "Jeroen Massar" <[email-masked]>
> Scott Leibrand wrote:
>> 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.
>
> Wow, a /22 IPv6 space, that is a big chunk. But I assume
> you mean /22 IPv4. What has IPv4 to do with IPv6 ...

The least controversial means of getting PIv6 passed was to say that orgs 
qualified for it if they also qualified for PIv4.  That bar is presently 256 
hosts (25% of a /22) if you're multihomed or 1024 hosts (25% of a /20) if 
you're not.

ARIN recently rejected a proposal to reduce the PIv4 bar to a /24 (i.e. 64 
hosts); there was a bit of grumbling about routing table bloat, but that was 
_by far_ overshadowed by concerns about spammers.

> 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.

You have it backwards.  Certain people in this WG were trying to force ULA-C 
on the community two years ago, and ARIN responded by passing PIv6.  That 
killed ULA-C, but it has risen from the dead and is again terrorizing the 
populace.  What do we need to do to kill it for good this time?  Garlic? 
Holy water?

> Clearly ULA-C is just "cheap address space", nothing more
> nothing less.

There is no reason to think that the RIRs' cost of registering and managing 
a /48 in fc00::/8 will be any less than the cost of registering and managing 
a /48 in 2000::/3.  Since all of the RIRs operate on a cost-recovery basis, 
that means the fees should be the same.  Ergo, ULA-C will not be any cheaper 
under the currently proposed model.

> 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.

Then it's time to either fix the policies or solve the id/loc problem.

> The RIR community effectively blocks people from getting
> address space on the premise that "but that costs routing
> slots", ... and then on top of that basing that decision on
> IPv4 address space usage, wow.

Qualification, not usage.  ARIN does not actually require you to apply for 
PIv4 space (or have a v4 network at all for that matter) in order to get 
PIv6 space.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: bill fumerola <[email-masked]>
Date: Fri, 6 Jul 2007 16:27:17 -0700

On Tue, Jul 03, 2007 at 03:47:50PM -0500, Stephen Sprunk wrote:
> a /48 in fc00::/8 will be any less than the cost of registering and 
> managing a /48 in 2000::/3.  Since all of the RIRs operate on a 
> cost-recovery basis, that means the fees should be the same.  Ergo, ULA-C 
> will not be any cheaper under the currently proposed model.

yes, and?

shouldn't that encourage people to get space allocated out of the block
(2000::/3, FC00::/8) that best suits them? they could request/register
out of both if they have a use for both. several cases have been made
on this list that people would have dissimilar uses for both.

what is the problem with allocating people what they want? the RIRs can
set their fee schedule as needed. that's not this WG's worry.

if i pay to have a ULA-[CG] block allocated/registered to me, i should
know that i'm not going to be able to sucessfully announce it to the
DFZ. the RIRs tend to do a good enough job explaining the difference
between the different types of address space available. given enough
direction and information from the documents produced here, i think
we can depend on RIRs to do the right thing.

-- bill