[ppml] /48 vs /32 micro allocations

[Hannigan, Martin]

As someone who is coming up to speed on IPV6, 
I am somewhat understanding where the WG is coming from and
I find myself tending to agree - and looking forward to
Orlando.

I think Bill nailed it. To me it translated to
it's better to drop what I don't want than to not get what 
I do want, which has been a theme to live by over the years.

Cheers,

-M<

--
Martin Hannigan                         (c) 617-388-2663
VeriSign, Inc.                          (w) 703-948-7018
Network Engineer IV                       Operations & Infrastructure
hannigan at verisign.com



> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On 
> Behalf Of Jeff
> Williams
> Sent: Wednesday, March 16, 2005 4:34 AM
> To: Jimmy Kyriannis
> Cc: Paul Vixie; ppml at arin.net
> Subject: Re: [ppml] /48 vs /32 micro allocations
> 
> 
> 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
> 
> 
>