[ppml] draft-ietf-ipv6-ula-central-02.txt use case (fwd)

[Scott Leibrand]

And a reply.  Isn't cross-posting great?  :)

---------- Forwarded message ----------
Date: Thu, 21 Jun 2007 17:28:26 -0700
From: Scott Leibrand <sleibrand at internap.com>
To: Paul Vixie <paul at vix.com>
Cc: ipv6 at ietf.org
Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case

Paul Vixie wrote:
> 
> by asking for a use case, i'm pointing out that if you can't be reached by
> an ip packet from "there", then your need to look up a PTR corresponding to
> an address in "there" is unfathomable.
>

I get that.  But just because I *do* have IP reachability to "there", that 
doesn't mean my local resolver is configured to go "there" for DNS resolution. 
That's why I need to have a delegation chain pointing to the appropriate name 
server over "there".

>> I guess what it comes down to is that the intended use case for ULA-C is to
>> connect a bunch of companies with private address space on a private
>> network.
>> 
> 
> the idea that someone would only need PI for "public networking" is bizarre.
> quite a lot of normal IPv4 space is never advertised into the "default free
> zone" but it's universally unique and used "privately" with passion & verve,
> and there is no reason to expect that IPv6 PI won't be used the same way.
> 
> a global RIR policy to support this "private network" use case would suggest
> that each RIR lay aside a /32 worth of space that was meant to be carved up
> in /48 chunks for folks who needed smaller chunks of address space for 
> private
> networking, with advice to the community that no address space in these /32's
> be advertised to the DFZ, and that it be filtered out if seen in the DFZ.  an
> RIR could theoretically come up with a "private space only" membership class
> with lower fees.  whois and PTR-space NS RRsets would be managed normally.
>

You just did an excellent job of describing ULA-C.  The only difference is that 
ULA-C is being specified top-down through the RFC process, rather than being 
put together in an ad-hoc bottom-up process that may be different for each RIR.

> i think the disconnect here is that a lot of folks are assuming that the RIR
> system only allocates "public" address space.  that's not true today, and it
> never has been true (compare historical allocations vs. DFZ advertisements),
> and there's no reason to try to make it true or to assume that it ever will
> be true.  RIRs allocate universally unique space.  how it's used (public vs.
> private) is not an RIR concern.
>

It is true that someone who can get a PI allocation can use it for internal use 
just as they would with ULA-C.  However, since someone who can get a PI 
allocation can easily put it in the DFZ, the RIR membership has made 
restricting the distribution of PI  space an RIR concern through the policy 
process.  The RIRs could elect to allocate private-use-only PI out of a special 
block, but such space is less likely to remain out of the DFZ, because the 
designation of it as not-to-be-routed would not carry the force of an RFC 
standard, and there would not be a single block (FC00::/7) to filter, but 
several different blocks, one from each RIR who chose to create private-use PI 
space.  As such, I believe that the IETF should designate ULA-C and hand it off 
to IANA and the RIRs to manage, rather than having the RIRs designate 
private-use-only PI space.

-Scott