[ppml] draft-ietf-ipv6-ula-central-02.txt use cases

[Per Heldal]

On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote:
> If we want to issue address space to folks for "private" use, it needs to be 
> out of the same block(s) that the RIRs use to allocate space for "public" 
> use, because sooner or later those "private" networks are going to end up 
> being publicly routed.

But if we do this shouldn't we also take steps to prevent abuse
(hijacking etc) of those "private" blocks. History has shown that
unannounced PI-blocks that nobody is missing can be abused for a long
time before anybody cries foul. We may have made a hash of v4, but
shouldn't have to make the same mistake from the start with v6. Maybe
RIRs should announce "private" or otherwise "quarantined" blocks from a
special AS so that they can easily be identified and filtered ...
although they'd end up wasting space in the DFZ (whatever that is;).

... which is closely related to the following:
> 
> If we are concerned that giving "real" PI space to every org that asks for 
> it will result in the immediate death of the DFZ, then there needs to be 
> some sort of tag attached to blocks that says whether or not the registrant 
> has met whatever the current rules are for deserving a routing slot.  If 
> routing certificates ever take off, they could contain a flag that gives the 
> current public routability status, or the RIR could just not issue a 
> certificate at all if someone hasn't met the bar.  That's an entirely 
> separate matter from whether or not they get addresses.

Until there's a reliable mechanism to verify the origin of a prefix all
we can do is try to cope through policies. Is the lack of
route-certificates an excuse to not try to do something about the
problem in the meantime?


> 
> One could also argue that the RIRs do not belong in the routability decision 
> path at all, since their job is to ensure uniqueness, and some other 
> quasi-public entity responsible for the health of the DFZ would produce 
> "routability" certificates.  That also gives rise to the possibility of 
> different models than we have today, like a market where people could buy 
> and sell routing slots.

Isn't that like calling for a "global internet constitution"?

What about a mechanism to establish some form of "common ground" on
which routing-policy-decisions can be made. To "navigate" the world of
routing an allocation-policies today is like navigating an aircraft
without the ability to adjust the altimeter for varying air-pressure.
There are too many inconsistent and independent sources of information
with widely varying quality and formats. Things would be easier if
inter-domain-routers were required to form a relation to
address-registries for all network-domains in which they wish to operate
(normally ARIN + RIRs + possibly private) in addition to whatever
routing policies each operator choose to implement (in reality they
already do but the quality that information tend to vary a lot with
operator clue). Registries would then have to announce the allocation
policies (blocks and prefix-lengths) through standardised formats and
mechanisms/protocols available globally. Address-space that is not
covered by a policy would by definition be unused (hence the need for
separate bogon-filtering and the related debogonizing-issues would be
mostly eliminated). 

Combine this with:

- A strong recommendation from address registries to announce aggregates
for optimum visibility/routability (note: _recommendation_ not
_requirement_). In reality this is just a formalisation of current
practise.

- Standards which must require IDR implementations to never drop
aggregates even if the available set of more-specifics cover the entire
block specified by the allocation policy. A 3rd party might choose to
ignore the smaller blocks and would loose "visibility" without the
aggregate. (note: path selection algorithms based on
longest-prefix-match would not be affected).

(- Maybe even a BGP node should be able to tell its peer(s) that it
doesn't want to receive routes more specific than allocation policies.
Although it might be hard to ensure that different ASes conform to the
same allocation policies.)


With such a thing in place one would at least have a fair chance of
knowing how local routing-policy decisions might affect routability. Now
you can safely ignore TE-churn from distant networks while choosing to
accept more specifics from peers and others in your "neighbourhood" and
still feel reasonably confident that you're not loosing anything
important.

In a better world that has route-certificates and unlimited
IDR-scalability this makes no sense, but will we get there in time to
avoid trouble.


//per