Re: [ipv6-wg] Re: Re: [address-policy-wg] Re: Andre's guide to fixIPv6

["Cameron C. Gray" <]

Kurt Erik Lindqvist wrote:

>> I think this hit the nail on the head.  Providers (especially those
>> non-LIR) will not accept something along the lines of SHIM6 or A.N.Other
>> competing idea until it gives them just that -- INBOUND ROUTING
>> INDEPENDENCE.
> 
> Now you are mixing two issues that Per separated though. Per pointed out
> that shim6 is work in progress while we need a policy now.

Kurt,

I agree with you they are separate concerns, however as I pointed out
they must be addressed similarly if IPv6 is to be adopted on any
meaningful scale.

I think as far as possible policies should speak to the assumed use and
be extensible rather than a stopgap - "we do it this way now, but we now
its not good and will change".

My point was that yes SHIM6 is a work-in-progress but is not a solution
that non-LIR providers will accept willingly; many would rather welcome
doomsday of no more address space than work with something that limits
their independence.

Addressing previous criticisms,

As far as the recurring argument of investment to support growing
routing tables and memory requirements - how many of you had this when
specifying individual hosts?  Why can't every server just have the 64K
Bill Gates promised would be enough?  And wait, didn't he also say the
Internet wasn't worth worrying about?  Routing equipment will grow and
adapt to the technical needs and business will have to fund it or send
their customers elsewhere, its an evolution not something we all have to
be protected from.  (Not that RIPE is a place to dictate business cases
and budgets anyway...)

Can anyone digest for me into simple bullet points the other arguments
for not allowing end site multihoming (and possibly PI therefore), other
than:
a) routing table size and therefore equipment concerns
b) growing/padding RIPE membership numbers
c) other immature solutions which border on NAT-insanity which don't
actually address the independence angle

I see the a) and c) above as cosmetic and easy to work around, and i
think that b) would only be a good thing (tm) as all our fees drop with
more members.  Otherwise I can't see any more limiting factors to
running it almost the same way as v4, instead of multiple prefixes per
applicant its one.

-- 
Best Regards,

Cameron Gray
Director, Netegral Limited
www.netegral.co.uk | 0871 277 6845