[arin-ppml] Rationale for /22

[Kevin Kargel]

I haven't been following this closely, sometimes work intrudes, but have we
all forgotten all the rationals that say that unaggregated /24's break
things?  Or are we assuming that everyone will be able to handle huge
routing tables or are we assuming that the /24 recipients don't care if they
can route beyond peers?  

I realize that IP's will become a smaller pool, so maybe the thinking is
that when this triggers there won't be enough /24's left to significantly
affect the routing tables?

I am still in the camp of "Keep doing what we are doing and when it runs out
it runs out."  Rationing is not always a good idea.  Trying to stretch out
resources indefinitely will be an exercize in futility.

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Joel Jaeggli
> Sent: Tuesday, July 28, 2009 9:33 AM
> To: William Herrin
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> 
> 
> William Herrin wrote:
> > On Tue, Jul 28, 2009 at 4:43 AM, Joel Jaeggli<joelja at bogus.com> wrote:
> >> Bill Darte wrote:
> >>> Every effort to lower minimum allocations throughout the years has met
> >>> with resistance.  Each successful policy managed a 'bit at a time' to
> >>> ensure 'nothing bad happened'....
> >> Realistically is it in the interest of a prospective multihomer to a
> >> recieve a prefix that's likely longer than the one they already use?
> >
> > Joel,
> >
> > I don't follow your logic here. Why would a multihomer request less IP
> > addresses than he already uses, regardless of the minimum prefix size?
> >
> >
> >> How quickly does one chew up /32s /30 /28s in the process of
> multihoming
> >> the internet facing infrastructure in a smple-multihomed network?
> >
> > When I was at the DNC, I structured the network to justify a /22. I
> > really wanted a /23 but a /22 was what I could get.
> >
> > I'm faced with a similar situation today. I need a /24 but I'll
> > structure the network so that it justifies a /22. Just to be clear, I
> > won't tell a single lie. I'll simply structure the network so that
> > everything which could consume a public IP address does.
> >
> > I doubt my experience is unique. I expect that many if not most of the
> > /22 end-user requests are similarly padded, not because the registrant
> > actually wants that many addresses but because that's what they can
> > get.
> >
> > Given the shortage of IPv4 addresses, why structure the policies so
> > that we give anyone more than they actually want?
> 
> 
> The minimum number of addresses that can be used may not in fact reflect
> the minimum that should be used.
> 
> 	For the purposes of minimizing fragmention.
> 
> 	Supporting basic network operation (it's nice when traceroute
> 	and pmtud work) because your intermediate routers are privately
> 	numbered.
> 
> 	Limiting the consequences of imagination failure, which may
> 	sound flippant but renumbering, requesting an additional block,
> 	or and point one and two are good reasons to make a potential
> 	multi-homer justify the assignment of a block of the appropriate
> 	size for that activity.
> 
> 
> > Regards,
> > Bill Herrin
> >
> >
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090728/17197b6e/attachment.bin>