Re: Fwd: [ppml] Policy Proposal: IPv6 Assignment Size Reduction

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

On Tue, 30 Oct 2007 12:52:54 +0000
Jeroen Massar <jeroen@unfix.org> wrote:

> Mark Smith wrote:
> > Iljitsch van Beijnum <iljitsch@muada.com> wrote:
> > 
> >> I thought this would be interesting reading for the working group.
> >>
> > 
> > I think the best thing to do is ignore it. If it gets any traction in
> > ARIN, then we might have to do something.
> > 
> > (I'm embarrassed to be listed in the acknowledgements section of the
> > related draft, because it can imply I agree with it - and my position is
> > the complete opposite - I'm even fairly strongly anti-/56.)
> 
<snip>
> 
> A proposal for changing the /48 boundary for *home users* to /56 though
> might at a certain point be a good idea. Companies should be getting a
> /48 IMHO.
> 

(Note to ARIN people who might receive this, below is written for the
V6OPS list, which is where this issue was brought up. I'm not addressing ARIN
policy, and I'm not effected by it either, as I'm in the APNIC region. Thanks.)

As an operator, my objection to /56 is that I like the simplicity of
being able to always assume an end customer has a /48, regardless of
what type of customer they are. The moment there are /48s or /56s, that
means every single time I'm talking about customer address space, I'd
have make sure or be sure it's clear to the other person or people that
it's a /48 or a /56, meaning that every time I discuss it, I have to
state it. It's a small cost, but one repeated many many times. It also
creates an opportunity for error. /48s everywhere means one less thing
to break.

If customers were to get a /56, I'd probably be reserving the /48
that the /56 falls within to allow for that customer to grow without
having to renumber. At some point in the future they might call me up
and say I want to grow my /56, and I'd be saying, just shorten your
prefix length. I figure since I'd be reserving the /48 for them anyway,
I can even eliminate that cost of dealing with that query, and give
them the /48 from the outset. I should never hear from the again, at
least about addressing issues.

I'm fairly strongly against /56s just because fundamentally it is extra
complexity for which I can't see much practical benefit. I'm
not absolutely against it though - it's something I'd compromise on
because in the big picture, the increased complexity costs aren't all
that significant, and if, over time, it helps people get used to giving
enough address space for convenience, not for necessary funcationality,
then I'll wear those costs.

More than two boundaries though is something I'm absolutely against.
That's unnecessary complexity.

Regards,
Mark.