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 > ([EMAIL PROTECTED]). > Manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------