[AfriNIC-rpd] Opposition to AFPUB-2010-v4-005-draft-01

[Andrew Alston]

Just one other thing I thought about as I was climbing into bed J

 

In a world where /24 is the minimum allocation size and that's whats
globally filtered on, when someone hijacks space out of a larger block,
they announce a more specific and if their announcement is accepted
globally, they have pretty much successfully hijacked the space for a
while (similar to what happened to youtube a while back).

 

Now, at the moment, if you deaggregate to /24s, it makes hijacking your
space a little more difficult, since its equal prefix length size, the
guy hijacking may get partial reachability, but the routes of equal
length will be competing.

 

Drop the minimum allocation size to a /27, and to achieve the same
effect, you're gonna have to deaggregate to /27 size rather than down to
/24 size.  Welcome to yet another reason this clause will bloat the
routing table.

 

Thanks

 

Andrew 

 

 

From: Daniam Henriques [mailto:daniam.henriques at gmail.com] 
Sent: Tuesday, March 01, 2011 12:45 AM
To: Andrew Alston
Cc: McTim; Stacy Hughes; rpd at afrinic.net
Subject: Re: [AfriNIC-rpd] Opposition to AFPUB-2010-v4-005-draft-01

 

 

On Mon, Feb 28, 2011 at 11:52 PM, Andrew Alston <aa at tenet.ac.za> wrote:

Hi Tim,

As per my previous email, yes, it does, clause 3.5.2 lowers the minimum
allocation size to a /27, which I think is hugely problematic.

Thanks

Andrew



-----Original Message-----
From: rpd-bounces at afrinic.net [mailto:rpd-bounces at afrinic.net] On Behalf
Of McTim
Sent: Monday, February 28, 2011 11:22 PM
To: Stacy Hughes
Cc: rpd at afrinic.net
Subject: Re: [AfriNIC-rpd] Opposition to AFPUB-2010-v4-005-draft-01

Dear IP Goddess,

On Tue, Mar 1, 2011 at 12:07 AM, Stacy Hughes <ipgoddess.arin at gmail.com>
wrote:
> Esteemed Colleagues,
> I must speak in opposition to this proposal.
> First, I am philosophically opposed to soft landing proposals in
general.
>  When the party is over, it's time to go home.  We don't get 5 more
minutes
> or more birthday cake.

Have you ever been to a 1st graders birthday party???....they get the
5 more minutes AND more cake...I experienced this first hand a few
days ago ;-/

  Incorporation of and transition to IPv6 is the way
> forward, and necessary for all of us.


Full ACK

>
> I especially disagree with direct assignments or allocations of IPv4
space
> in subnets of longer prefix lengths than /24.

Does this proposal do that?  If so, I must have missed that in this
iteration.

Personally, I too would disagree with the allocation of prefixes that
are greater than /24 in length.

While one could argue that filtering could be amended to facilitate such
a requirement, a number of technical issues, some of which have been
raised by Andrew Alston, exist which would mean that such a decision
would have far reaching consequences related to current hardware and
software limitations.

Individual and regional providers may be convinced to update their
filters, however this is something which would require global buy-in
with the major service providers and transit providers of the world.
Without service providers agreeing to accept these longer prefixes,
those that have been assigned these prefixes will be unable to make use
of them in any meaningf

Additionally allowing /27 or greater subnets to be received within the
global BGP table and to view such advertisements as acceptable will most
likely promote further de-aggregation of the global table as various
providers de-aggregate their existing subnets to achieve traffic
engineering.

	--
	Cheers,
	
	McTim
	"A name indicates what we seek. An address indicates where it
is. A
	route indicates how we get there."  Jon Postel
	_______________________________________________
	rpd mailing list
	rpd at afrinic.net
	https://lists.afrinic.net/mailman/listinfo.cgi/rpd
	_______________________________________________
	rpd mailing list
	rpd at afrinic.net
	https://lists.afrinic.net/mailman/listinfo.cgi/rpd

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20110301/e79d9a34/attachment.html>