> FWIW, I don't agree with Michael about assigning /56s. I used to think
> that /56s for residences made sense. And in reality, most residences
> will be fine with 256 subnets. However, having now gotten some
> operational experience with IPv6 and having reviewed the math, I now
> believe there is no true rationale behind assigning /56s.
> 
> Very large providers should seek to get larger blocks rather than
> accepting the default /32.

I'm not saying that very large providers SHOULD give /56 assignments
to private residences. I am saying that ONLY VERY LARGE providers
should consider giving less than a /48 to private residences.

Applying for an allocation larger than a /32 is a very good idea
for large providers to do.

>    Is there something wrong with the math (are big-isp's going to
> run out of /48's)?

For those who REALLY want to study the math, look at this presentation
http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-ipv6-roundtable-report.pdf
which explains how we might be getting a bit short of addresses in 60 years.
This presentation led to policy proposal 2005-8 https://www.arin.net/policy/proposals/2005_8.html
and you can see some more background info by following the URLs on
the 2005-8 page. 

>    If it is ok for Comcast customers to get /56's, why isn't it ok
> for all other private residences to get /56's (what are the /56
> customers giving up)?

It is not OK for Comcast to do this, but we have given them the choice.
But if you are not Comcast then it would be foolish to do things the
way that Comcast does.

Just stick to /48 for everyone, and make your projections on that basis.
You are not wasting anything because /48 per endsite is the design spec
for IPv6. ISPs should not be trying to reinvent IPv6, just deploy it as
it is, get your /32 and design your addressing plan based on a /48 per
endsite. Internal addressing is a bit more complex, but it is worthwhile
to start by assigning a/48 to each of your endsites and projected endsites
and only aggregate if really needed.

--Michael Dillon

_______________________________________________
ARIN-Discuss
You are receiving this message because you are subscribed to
the ARIN Discussion Mailing List (ARIN-discuss@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-discuss
Please contact info@arin.net if you experience any issues.

Originally sent: Date: Wed, 15 Sep 2010 11:27:09 +0100
Re-queued by ESC7NET: Mon Sep 20 23:47:41 2010