[ppml] /48 vs /32 micro allocations

[Jimmy Kyriannis]

Yes.  One might also view that the sparsity of routing entries would 
constitute an environment in which would be "harder to get away with" 
hijacking, since filtering longer length prefixes creates a population of 
much more visible/impactful prefix targets to hijack.  In that vein, if a 
longer prefix were to "sneak into" the routing tables, it would also be 
rather visible.

Either way, IMO, the fundamental problem of route hijacking won't be solved 
here, since it doesn't lie within the filtering of routes, but rather 
hardening the protocols which make this possible for disreputable or 
unaware providers.


Jimmy

At 09:17 AM 3/15/2005, Paul Vixie wrote:
> > I can think of at least one...
> >       The greater the sparsity of address utilization, the easier
> > it is to hijack portions of the address space.  That, in and of itself,
> > to me seems like a good reason NOT to pursue a sparse allocation policy.
>
>this is nonsequitur.  ipv4 is a lot smaller and denser than ipv6, and yet
>spammers routinely advertise ipv4 blocks, spam from them for a few minutes,
>and then withdraw the route before most folks get around to traceroute'ing.
>
>we're going to need some form of end to end bgp authentication no matter
>whether we move to ipv6 or not, or do so with sparse allocations or dense.