[address-policy-wg] 2011-04 New Policy Proposal (Extension of the Minimum Size for IPv6 Initial Allocation)

Jan,

On Wed, 2011-10-26 at 12:47 +0200, Jan Zorz @ go6.si wrote:
> On 10/26/11 12:05 PM, Mikael Abrahamsson wrote:
> > On Wed, 26 Oct 2011, Jan Zorz @ go6.si wrote:
> >
> >>> I also feel that 6RD justifies a /32, it doesn't justify a /30 or alike.
> >>
> >> No. 6RD in it's natural form "needs" /24 in order to give /56 to users.
> >
> > Yes, "needs" indeed. It's not a MUST though, it's just operationally
> > easier.
> 
> Exactly.
> 
> But... (there's always a but), operators are yelling about small 
> margins, about not having money to invest in more complex operations, 
> about operations overhead and so on and so on.
> 
> Personally, I would go with multiple 6RD domains and be done with it.
> 
> Again, this are facts, complains and questions we get from real life on 
> the operational field.

Knowing you represent Go6, I do wonder what operators are requesting
this.  It wouldn't hurt if they came here and voiced their opinions
directly either. The APWG-ml community is not a 1:1 map to RIPE region
operators, so the community response you will get here may or may not be
what you want.

> > With 6RD you can take a IPv6 /36, map 8 bits of IPv4 into a IPv4 /24,
> > map 24 bits into IPv6, and now you have that /60 you wanted for your
> > customers. Yes, you "wasted" an IPv4 /24, but if you're that big so you
> > need avoid doing 6RD on IPv4 /16 level (map 16 bits of IPv4 into a
> > single IPv4 6RD relay address), give that relay a /40, then you can give
> > your customers a /56, "wasting" a single IPv4 address per /16 with some
> > additional configuration.
> >
> > Just to give some perspective if someone still thinks one can't deploy
> > 6RD without mapping all of IPv4 space into IPv6. It's not true, it's
> > just more complex.
> 
> Yes.
> 
> Easily possible, but not heavily practiced in real life. Least possible 
> complexity, least possible operational overhead. If we get them this 
> option, IPv6 service gets deployed. Note the usage of the word 
> "service", not "native" :)

I wish it was feasible to counter-suggest that those who spend more
effort get a better service to customers and 'market forces' takes care
of the rest (ie, native IPv6 provides the best service, and competition
eats up those 15 year old DSLAMs...).

(On second thought, isn't it?)

IMHO, we're not necessarily helped with deploying IPv6 services at
unlimited cost. And being too lazy to not map 32 bits of IPv4 space into
6RD strikes me like such a thing (and if you want to do it, you still
could, with the A,B,C and attached justifying documentation.)

Best,
Martin