Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addr

To: sig-policy at lists dot apnic dot net
Subject: Re: [sig-policy] Need to understand logic behind assigning /64 IPv6 addresses
From: Mark Tinka <mtinka at globaltransit dot net>
Date: Sat, 17 Sep 2011 23:36:08 +0800
Cc: Randy Bush <randy at psg dot com>
Delivered-to: sig-policy at mailman dot apnic dot net
In-reply-to: <m2d3f0g7jc.wl%randy at psg dot com>
List-archive: <http://mailman.apnic.net/mailing-lists/sig-policy>
List-help: <mailto:sig-policy-request@lists.apnic.net?subject=help>
List-id: APNIC SIG on resource management policy <sig-policy.lists.apnic.net>
List-post: <mailto:sig-policy@lists.apnic.net>
List-subscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=subscribe>
List-unsubscribe: <http://mailman.apnic.net/mailman/listinfo/sig-policy>, <mailto:sig-policy-request@lists.apnic.net?subject=unsubscribe>
Organization: Global Transit International
References: <1316160581.25312.YahooMailNeo@web110211.mail.gq1.yahoo.com> <m2d3f0g7jc.wl%randy@psg.com>
Reply-to: mtinka@globaltransit.net
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.7-desktop; KDE/4.6.0; i686; ; )


> the downside of this would be that the customer could not
> use auto-conf on their lan.  the general religion on the
> subject is that ipv6 space is effectively infinite (a
> tenet to which i do not subscribe), and a very large
> allocation, e.g. /48 or shorter, should be assigned to
> each customer.

I'm of a similar view, that v6 address space being viewed as 
infinite is a position I do not support.

We just have no way of knowing what will happen in the 
future to accelerate the use of v6 address space.

> /56 and /48 are commonly used sizes.

Aye.

We assign /56 to customers generally. This vastly increases 
the number of customers we can support than if we took a /48 
model; 65,536 assignments vs. 16,777,216. I'll say...

Do we still think a /56 is wasteful? Probably! But the 
imposition of SLAAC on /64's makes this all the more 
ridiculous.

Mark.

Attachment: signature.asc
Description: This is a digitally signed message part.