Hi, Daniel Roesen wrote:
On Thu, Nov 17, 2005 at 05:26:20PM +0100, JORDI PALET MARTINEZ wrote:
There are lots of similar examples as the NATO one. It make no sense at all
Not issueing PI for multihomed entities makes no sense at all, in face of the complete lack of a full replacement. I'm still waiting for the heads to come out of the sand, but I'm waiting since long and don't see _any_ light at the end of the tunnel (don't anybody dare to say "shim6" if he/she doesn't want to disqualify her/himself immediately). The folks all having their own /32 already allocated to them and trying to limit independent address space to "service providers" (or those who manage to pretend being it, which seems to be easy) are still arguing for "not for them!" paradigm - easy position with having their own dishes already done.
ok, *handraise* That's not entirely true - while i have "my" /32, i'm still arguing against this current no-PI situation every this and then (i stopped getting involed in _every_ IPv6-PI-related flamewa^Wthread long ago though...) But indeed, that's still the main problem, that people don't get their head out of the sand, largely due to just not seeing this problem as an issue for themselves.
Until we have a clear full replacement (that means a solution which does NOT ignore real requirements like shim6 does) there should be a very simple PI policy which issues a /48 or whatever to end sites at a nominal small fee, paid directly to the RIR. An initial setup fee and a yearly renewal fee, paid by credit card or something equally simple. No payment => assignment withdrawn. The initial fee covering the cost of evaluation of the request, doing the assignment and setting up the billing account and DNS reverse. The yearly fee covering the maintenance of the entries in the database and DNS rev NS RRset and the yearly recurring fee invoicing/billing. Done.
Too simple, too scary, too much independence again to the endsites, eh?
I think, the main argument against IPv6-PI _still_ is the routing table size, contradicting any reasonable predictions nowerdays (IMHO!). At least that was my own argument against(!) PI in first place, but times have changed since the last millenium. In particular, noone came up with an equal solution to BGP Multihoming with "PI"-space, which i hoped for back then. I can't even see any solution rising in the FAR future, so the only way to keep IPv6 from being completely useless is, go for allowing PI Space for organisations who really want that geniune kind of multihoming and are sure they don't want any workaround solution. A setup+renewal fee does not do much against the routing table size or so, but at least should stop having the IPv4-situation with swamp space(s) and unused, unowned or "joke" Prefixes floating in the databases. I wouldn't like to have anyone to get a Prefix without reasonable need just for the fun of it, like with el-chepo Domain-Names and Hostname ect.. One should know what he does. Of course the issuing organisation should point to alternative solutions and have the requesting one to check out on them if they might be sufficent for their needs (the famous "Did you consider using RfC1918?"-alike-question in the request form should do it with some pointers to good FAQs on alternatives).
I think it's ridiculous to have folks become LIR (and pretend/lie being ISPish) just to get the PI space they need and having them pay the same money every *real* LIR (you remember what LIR means? Local Internet REGISTRY) which happens to open tickets with the hostmasters every now and then (or much more often).
ACK. That's ridiculous. Additionaly, some might not NEED a /32 and don't want to pay for services they don't need (Registry servies, voting@RIPE-meetings, Training Courses... whatver)
Setting aside my disbelieve in the FUD about the scalability problem of real BGP multihoming (noone yet has shown that the relative amount of multihomers does or will explode), I'm quite sure that we'd need a real locator/ID split which is NOT shim6 but something going farther than that. And we won't have it soon, if at all for IPv6. But keeping on ignoring user's needs for further years and waiting for the magically appearing 100% ideal solution is not the way forward.
Well, if i say "there is no scalability" problem, that would be considered ignorant by most people, so i don't do that now. But i can't see any problems with BGP routing table size either, it will be significantly smaller than in the IPv4 world by design (one - or few - prefixes per AS), and even when it's growing again from PI-prefixes, probably beyond the current IPv4 table size, what's the problem? Nowerdays routers actually can handle that with >=1GB RAM and fast ASICs. ... and it will take YEARS if at all to raise above nowerdays size. Now let alone the fact that you need to carry on with the IPv4 table for decades anyways, so no relief in sight for the routers... But i'm not saying, there won't be a problem in 50years.
My 0.02EUR
I add another 0.02EUR
Regards, Daniel (having renumbered his IPv6 network already three times completely and hoping not having to do it a fourth time anytime soon, and not being able to properly multihome like I can do in IPv4 because I'm not a commercial ISP, nor can afford the thousands of EUR for LIR which usually finance MUCH more than just a one-time PI assignment and some DB slots)
...i rather invest in redundant Uplinks and routers than in becoming LIR for no apparent reason (i.e. not ASSIGNING Address space as primary purpose), hence i currently go for IPv4-PI for my non-profit organisation(s), utilizing a /40 Suballocation in the IPv6 world from "my" (commercial) LIR. Better than nothing but i'd prefer a completely independant IPv6-PI space and someone doing something against this /32-/35-filter-madness. "My" LIR is not very active in the ISP business lately, and i don't want to know how to deal with a CLOSE of the LIR with my more private, non-profit Address Space either. Am i allowed to keep the Suballocation when RIPE reclaims the LIR's /32? Can i announce the whole /32 when i can't reach some locations with the /40 Suballocation announcement? Can i have the whole /32 for free then not being a LIR? Do i ultimately have to renumber, too? How often? How do i maintain my multihoming properly? ...and so on...(NOTE: rethorical questions, i know the current procedures on the paper) <arrogancy> Idependency is one of the basic things in the internet, i don't like people who want to tell me how much independency i need. I know that best for myself. </arrogancy> -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================