|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: 16 vs 32 bit ASNs [Re: BBC does IPv6 ;) (Was: large multi-siteenterprises and PI]
Multihoming can be such a reason. Get DSL and cable to your home, request an AS number, request PI space, run BGP to multihome, etc. In which case, it's legitimate. OTOH, I have a SOHO with a legitimate ASN and protable IPv4 space. Who are you to tell me that it isn't legitimate for me to use it in this manner? Why do you get to decide that my SOHO is less worthy of PI space and the ability to reliably multihome just because my organization is small?Because I have a similar organization myself, and I'm unselfish enough to realize that the organization is not sufficiently relevant in the global scale to be using such a mechanism. Why is my organization any less relevant on the global scale than say: AS56 (Optimis Division of the Pentagon) (No routes according to route-views.oregon-ix.net) AS58 (Defence Research Establishment Atlantic) (No routes according to route-views.oregon-ix.net) AS62 (Teknowledge, Inc.) (No routes according to route-views.oregon-ix.net) AS68 (Los Alamos National Laboratory) (Originates a /16 _AND_ a more specific /24 from that /16 _ALL_ behind AS293 -- singlehomed) AS78 (Syntegra (USA), Inc.) (Originates 2 /16s, 2 /24s, _ALL_ behind AS5006 -- singlehomed) AS85 (The Aerospace Corporation) (No routes according to route-views.oregon-ix.net) AS94 (Army Belvoir Research and Development Center) (No routes according to route-views.oregon-ix.net) And why do you get to decide for me? This is just the ones I found in the first 100 ASNs that seem to beg the question above. Scalable? NO. Not just the number of routes, but also the churn those routes would make.. Oh god.So we return to the need to separate the end-point identifier from the routing identifier and come up with a routing scheme that allows routing assignments to be dynamic and flexible independent of the layer 3/4 endpoint identifier.Yes. You seem to be arguing that because we don't have such identifier split _today_, we must open the doors to give _everyone_ PI and ASN and to pollute the global routing table. I'm not saying that we need to give everyone PI and an ASN, but, I am saying that this was one of the critical problems the community expressed early on in the v6 development process. It has been ignored. Therefore, don't expect the community to embrace v6 and v6 policies that simply address the issue by saying "too bad, you loose, move on.". I say we must close the doors even more, so that those who would need multihoming solution would pick the one based on identifier split, instead of getting the one which pollutes the global resource. Then present the one based on identifer split and get it implemented in routers. Until then, real needs are real needs and people will use what is available. If they can't get what they need in v6, they'll stick to v4 where they can. If we make getting PI/ASN too "cheap" (using various metrics for "cheap"), nobody wants to get an identifier split solution. If you make it too expensive, people will route around you as damage. Obviuosly, you don't subscribe to the premise that regardless of reclamation, we will run out of 16 bit ASNs soon enough. That's fine, you may be right. However, from where I'm sitting, I think we will. I also think that the $500 up front cost and $100 annual renewal associated with an ASN are decent incentive for people not to get them unless they have a legitimate use for them. Private ASNs are too easy and cost nothing.if the prices were one or two orders of magnitude higher, that might be true. That's way too cheap as it is. 10000$ upfront, 5000$/yr for renewal might scare away who _really_ don't need them. Have the RIRs donate the markup to ISOC or whoever and we're done. So, you think that global resources should be allocated solely on the basis of wealth. Well... I don't subscribe to that theory, so, on this we will certainly have to agree to disagree. Owen -- If it wasn't crypto-signed, it probably didn't come from me. Attachment:
pgp00138.pgp
|