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

[shamilton at exactor.com]

  I totally agree with Stephen and others than regardless of original
intent 'private' PI routes will end up public, whether by intention down
the road, by accident, or by hi-jacking.  It strikes me that the way to
address this is after the allocation process by means of routing
authentication only - RADB and it's ilk now, certificates later maybe. 
Call me naive but I thought a key factor in v6 deployment is that there
is enough to go round so NAT / PA will not be forced onto organizations
that don't want it - surely it's enough of a burden to get PI space,
manage it in RADB/DNS, setup BGP, pay an ISP to receive your
advertisements (there's a whole other choke point here where ISPs can
institute their own policies on what is reasonable).

  I'm young and inexperienced compared to many of you I know, but I can't
see the IPv6 table being < 300K routes in a few years, but neither can I
see it being double that - whilst I see some pent up demand for
multi-homing using PI space, I also see many people who will continue
using NAT in IPv6 because that's their security guys dogma (it isn't
mine & I'm not interested in that whole discussion again).  It will
continue to require a degree of clue to participate in the global table,
and if people need to announce their aggregates to make things work
that's a lesson they will learn (or that their ISPs will share/force
upon them)

Regards

Simon Hamilton-Wilkes




> 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
>
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>