[ppml] /48 vs /32 micro allocations

[Jeff Williams]

Jimmy and all,

  I didn't get from Paul's remarks he was eluding to filtering.  I agree
also that hardening of Protocols is also a very good idea.  I believe
Paul has been moving in that direction as well...

Jimmy Kyriannis wrote:

> 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.

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827