Re: [address-policy-wg] Re: 200 customer requirements for IPv6

[Sascha Lenz <]

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@localhost,
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@localhost         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================