[ppml] IPv6 flawed?

ok.  you got me wondering...

Do you have any stats you can provide that show PA IPv6 being subnetted down more specific than a /32 and actually getting through routers that way?  And if yes, how many?  I would love to see the actual numbers.  I dont mean to be snarky, I just really want to know if this is really happening with PA space on large, medium or small scale.

And whether its perception or reality, I dont know.  I would love to see the stats on PI space being routed and successfully making its way through filters in anything more specific than the original allocation from its RIR.  I believe just based on the nature of how current policy is written in ARIN RIR for PI, it naturally lends itself to being used for multihoming and TE.

And just for the record.  Long live multihoming and TE!  ;o)

Cheers!
Marla Azinger
Frontier Communications

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
David Williamson
Sent: Thursday, September 06, 2007 9:31 AM
To: David Conrad
Cc: Public Policy Mailing List
Subject: Re: [ppml] IPv6 flawed?


On Wed, Sep 05, 2007 at 06:30:22PM -0700, David Conrad wrote:
> Since IPv6 uses the same  
> routing and traffic engineering technology as IPv4, I am curious what  
> constraints could be put in place to keep PI space down to about 1  
> per ASN.  Particularly given PI allocation policies either have been  
> or are being liberalized in all the RIRs (for sound economic and  
> business reasons, at least from the perspective of the Internet end  
> users).

I don't understand why you single out PI holders in this.  I'm
wondering how many ASNs now advertise more than 2 PI prefixes...I know
that the six ASNs I have some control over have single PI chunks
assigned to them.  I have an association with another org that has two
PI announcements from a single AS, primarily because one of them is
from the class C swamp.

I suspect that PA holders are just as guilty of deaggregation.  Outside
of TE or simple sloppiness, there's been a lot of business activity
that leads to a lot of mergers and associated extra announcements.

Finally, there's all of the PA space that's getting used for
multi-homing.  From a routing point of view, that's exactly the same as
PI space - it's some smallish chunk in the middle of some other block
that's still attached to a single ASN (and different from the parent
chunk).

I'm sorry, but I don't see how PI space (when used responsibly) is a
culprit in the growth of the routing table any more than PA space.  The
real culprit is multi-homing and TE.  Clearly, we should just forbid
that.  (Yeah, right.)

As a network operator, I entirely agree that the problem is going to
come to a head at some point, and things are going to break.  What
things break and how remains to be seen...but something has got to
change.

Personally, I suspect we're going to see more and more long IPv4
prefixes in the DFZ.  I don't think it's up to ARIN or the other RIRs
to figure out how that will work.  I do think it's up to ARIN to hand
out space in a sensible manner, possibly including longer prefix PI and
PA space.  The routing community is going to have to figure out how to
either:

a) scale the routing system appropriately, or

b) figure out how to value a specific prefix.

For the latter, consider if windowsupdate.microsoft.com was a single
VIP or set of VIPs that resides in a /29.  As an ISP, would you route
that /29?  You bet you would...or you'd lose customers to the guy that
is.  How do you differentiate the value of that /29 versus some random
/29 that appears in the routing system for something of much lesser
value?  I haven't the faintest idea on that.  If I did, I'd quit may
day job and start consulting full-time.

Anyway, now that I've ranted on this topic space a bit, I'm hoping
someone can provide some numbers to show that PI space is more
responsible than PA space for the deaggregation noted in the posts in
this thread.  I really don't see it as any different.

-David
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy
Mailing List (PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services
Help Desk at info at arin.net if you experience any issues.