[ppml] /48 vs /32 micro allocations

[Owen DeLong]

I agree this isn't a solution to hijacking.  I still believe that issuing
/32s to people who would get /48s under current policy will exacerbate the
problem, not improve it.  I propose we avoid exacerbating the hijacking
problem.

Owen


--On Tuesday, March 15, 2005 12:43 PM -0500 Jimmy Kyriannis 
<jimmy.kyriannis at nyu.edu> 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.
>
>
>



-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050315/dbd73f01/attachment.sig>