[address-policy-wg] Re: Re: getting second IPv6 PA as a LIR

On Tue, May 03, 2011 at 10:31:08PM +0200, Gert Doering wrote:
> Well, I remain to convinced that a typical end-user household can
> find uses for more than a 100 different *networks* - but then, it's by 
> no means mandatory to assign /56s, as the policy explicitely allows 
> assignments of /48 (which we discussed last year in Rome to make it 
> very clear how that is currently counted regarding usage ratio).

Right, but that doesn't help, as your allocation size is still being
judged by looking at /56s (that a /48 assignment is counted as 256
assigned /56 doesn't help at all). Think of prefix delegation pool
sizing when you have a lot of aggregation points.

> I can't actually say for which classes of networks a HD-Ratio of 0.94 
> will work, and for which classes it might fail.  It does give the ISP 
> quite some slack (for example, a /32 is considered "full" if an 
> efficiency of 37% is reached - as opposed to the 80% in IPv4 today
> [RIPE-512, Appendix A]).  If that is not sufficient or does not really
> "fit" real-world networks, maybe we need a different HD-Ratio, or a 
> different "fullnesss" metric altogether - your suggestions are welcome.

The point is, that HD ratio 0.8 allowed MUCH cleaner, nicer addressing
schemes with semantic/geographic/technical hierarchy encoded on nibble
boundaries than HD ratio 0.94. With the latter, far less encoding with
"one size fits all" approach on a certain level is possible, otherwise
we'd be screwed later.

When you go off-nibble, things become cumbersome for anyone reading,
planning, delegating (revDNS), routing - basically DEALING - with IPv6
addressing.

This may be viewed as "less luxury", but also as added operational cost.

Anyway, all off-topic in this thread. I just wanted to point out that
people already started to apply "IPv4 mindset" to IPv6 policy, even
before any significant deployment has taken place and operational
experience has been collected.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0