[ppml] /48 vs /32 micro allocations

bmanning at vacation.karoshi.com bmanning at vacation.karoshi.com
Tue Mar 15 00:03:24 EST 2005

On Mon, Mar 14, 2005 at 09:54:43PM -0500, Kevin Loch wrote:
> bmanning at vacation.karoshi.com wrote:
> > On Mon, Mar 14, 2005 at 07:08:38PM -0500, Kevin Loch wrote:
> >
> >> Is there any benefit at all to allocating a /48 to name servers and
> >> exchange points instead of a /32?
> >
> >     yes.
> For example?

	let me answer with some questions.  how much of your 
	ipv4 /20 that is your minimal delegation from ARIN
	is populated?  5 hosts?  20 hosts?  150 or even 300?
	how many addresses are you advertizing reachability
	to that have no hosts/applications active?   do you
	consider this a problem? if not, why not?
> >> There is no shortage of /32's, with 536 million of them in 2000::/3.
> >
> >     it does -seem- pretty large, doesn't it?
> I would argue that it is too large.  Do you really want
> 67 million possible routes?  Keep in mind that this
> is for "Aggregatable Global Unicast Address Format".
> It's very likely that if we relly did want 67 millions routes
> we would be using a different address format outside of 2000::/3
> since 67 million does not seem congruent with "Aggregatable".

	aggregatable is i n the eye of the beholder.  IPv4
	looked pretty huge back in the day.  trying to equate
	addressing potential over the next 20-30 years with 
	todays routing techniques/technologies is short-sighted
	at best.  and yes, i could conceive of wanting/needing 
	more than 67 million routes - back when we were first
	considering CIDR, i postulated to the BGP experts of the 
	day that we should plan for host routes in IPv4... which
	is exactly where we are now with IPv6.

	different address formats woudl be useful, but the inertia
	in the IETF is considerable.  so we live with what we have.
	IMHO, the 64bit boundary is silly and a number of proposals
	treat the lower 64 as cidr-able space.  
> >     ISPs are free to filter on any boundar(y/ies) that they
> >     see fit to.  Many (most?) filter on published RIR allocation
> >     boundaries, some based on IETF recommendations, and SOME
> >     based on customer demand.
> I agree but In IPv6 right now most appear to be filtering /49 and 
> longer.  Is the micro allocation policy having an affect on this?
> This is not about how you or I filter on our own network, it's about
> the de-facto minimums that result from RIR policy, intentional
> or not.

	i'd like to see actual data to back these assertions.
	at the end of the day i don't really care what "most"
	people are doing, i care that my peers and my transit 
	providers carry my routes as I instruct them.

> >> RIR filter suggestions do not seem to matter, but allocation
> >> sizes do.
> >
> >     Sort of.  No RIR delegation is explicitly routable. Routability
> >     is not an attribute of RIR delegations.  Routability is up to
> >     the respective ISP's.
> And most ISP's eventually filter to the lowest common denominator,
> and that determines the de-facto MRU.  RIR delegations have a
> substantial effect on that.

	again, i really don't care about most ISPs, just the folks
	i peer with and those i pay for transit.  those agreements
	set the MRU for the prefixes i care about.  those i don't, 
	i'll drop from my edge routers if i'm having troubles.  why
	should you know or care about what i do in my network and with
	/between my peers.   if you want to have an opinion that matters,
	set up peering with me and we can talk about what prefixes are
	of interest to you from me and what prefixes i wish to hear 
	from you. end of the day it is the routing slots in the routers
	that count...  not some random ISP in Norway.

> >> Market forces, technology limitations and end site assignment sizes are
> >> also factors but there is a real risk that RIR allocations will result
> >> in a smaller MRU than these factors otherwise would.  I'm not saying
> >> that using /32's for special allocations will prevent a /48 MRU, but it
> >> is irresponsible to ignore the effects that these /48 allocations may
> >> have.
> >
> >     There are other effects associated w/ large delegations that
> >     remain sparsely populated.
> Are there any allocations in IPv6 that will not be sparseley populated?
> Even in bits 0-48 I would argue that most will remain sparsely
> populated.  Only 56% of IPv6 allocations are even announced right now.

	Yes...  but you may never see them since you insist on filtering
	at a much higher degree of aggregation than is desired by the
	prefix injector... you may even have quasi-rational arguments about
`	hardware/software limitations in those legacy routing protocols that
	everyone uses... :)
	(anyone willing to listen to some /96 or /112 entries?  didn't think
	so... :)

> >> So, to be on the safe and responsible side, should ARIN set a minimum
> >> allocation size of /32 for *any* direct allocation regardless of type?
> >
> >     That would be bad - on many different levels.
> Please explain.  Even if consensus is that this is a bad idea we should
> have the reasons clearly stated.

	please answer the questions I posed above and then we can
	continue this conversation.
> Kevin Loch

More information about the ARIN-PPML mailing list