[arin-ppml] Rationale for /22

Tue Jul 28 11:53:53 EDT 2009

I believe that the reason there is not a huge problem with unaggregated
/24's is that there are not very many unaggregated /24's being delivered.

Current wisdom says it is a bad idea, so people are not doing it, so there
is not a big problem.

People very rarely poke sharp sticks in their eyes, so there is not a big
problem with eye injuries from intentional sharp stick jabs.  I do not
believe that poking yourself in the eye with a sharp stick should be ok
because there is not current evidence of a problem from that action.  

A few extra routing table entries from infrequent gratuitous /24's is not a
problem.  If we start flooding the tables with them it may be a problem.  As
I said before this will be self limiting because of the finite number of
/24's to hand out.

I am not stomping my foot and saying there will absolutely be an issue, I
would just like to be reassured that it has been considered.

> -----Original Message-----
> From: Scott Leibrand [mailto:scottleibrand at gmail.com]
> Sent: Tuesday, July 28, 2009 10:22 AM
> To: Kevin Kargel
> Cc: ARIN PPML
> Subject: Re: [arin-ppml] Rationale for /22
> 
> Let me ask the inverse (or is it converse?) question:
> 
> Do you have evidence that unaggregated /24's (still) break things?  I
> haven't seen any evidence myself in the last 5 years...
> 
> Thanks,
> Scott
> 
> Kevin Kargel wrote:
> > 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.
> >>
> >> -----------------------------------------------------------------------
> -
> >>
> >> _______________________________________________
> >> 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/de49e63b/attachment.bin>