[arin-discuss] IPv6 End User Assignments

Wed May 6 16:37:33 EDT 2009

Aaron,

  Was space-wasting the only reason you went with a /64 instead of
a /48 or /56?

  For your single point customers, is this /64 intended for use on
just a single PC?  Such as for example a DSL customer with just a single
PC plugged into a bridged DSL modem?  Do you consider a customer
who has a wireless router with 5-6 PC's on it as needing a subnet
ie /48?

Ted

> -----Original Message-----
> From: arin-discuss-bounces at arin.net 
> [mailto:arin-discuss-bounces at arin.net] On Behalf Of Aaron Hughes
> Sent: Wednesday, May 06, 2009 10:59 AM
> To: Matthew Wilder
> Cc: arin-discuss at arin.net
> Subject: Re: [arin-discuss] IPv6 End User Assignments
> 
> Matthew,
> 
> You are highly likely correct.  Regional aggregation will be 
> implemented by any reasonable ISP. Also, if ISPs did assign 
> /48s to each customer your math is correct, each ISP of this 
> massive size would need a /21ish.  Also, I agree a /48 is 
> excessive for each customer.  
> 
> For a moment we should separate policy from operations.
> 
> As architects in the planning phase of a v6 roll-out we get 
> to plan for company needs, customer needs, aggregation, 
> reachability, scalability, etc etc etc. One of the aspects we 
> should all evaluate is wasting space.  
> 
> When I rolled out v6 to my customers, I made the company 
> policy decision to assign /64s to customers by default and 
> /48s to those who requested more than one subnet.  This made 
> it rather easy to have 2 pools of aggregatable regional space 
> for customer assignments.  The company policy / network 
> architecture fits within certain, what I will call, ARIN 
> guidelines in that it does not violate ARIN policy. Policy 
> has never dictated operational practice.
> 
> That being said, policy should _allow_ for an implementation 
> that requires /48 assignments to the LIRs respective 
> customers. There are implementations where this makes sense.  
> It is highly unlikely that very large ISPs will be assigning 
> 48s to each customer as it would be a waste of space.
> 
> This list, just like Planing / Design / Architecture / 
> Operations groups are full of opinions about how things 
> should be implemented. Time will reveal best practices and 
> policies will get updated to reflect them as long as the 
> operational community is involved in the policy process.
> 
> I am involved in many v6 implementations and none of them 
> assign 48s by default.
> 
> Cheers,
> Aaron
> 
> 
> On Wed, May 06, 2009 at 11:28:47AM -0600, Matthew Wilder wrote:
> > This is where it gets interesting.  I doubt the worst case 
> is a /23.  Remember, IPv6 has so many bits for  the very 
> purpose of clean summarization and easy subnetting.  
> > 
> > Comcast might want to regionalize their subnetting.  And 
> then within each region, they might want to have a nice big 
> block for each edge router so they don't have to constantly 
> add address resources to the router.  All of a sudden, 
> instead of assuming a 90% utilization of that block (which is 
> heinously unreasonable and inconsistent with IPv6 intentions) 
> you are looking at maybe 20 - 30% utilization at the /48 
> assignments.  Now they need probably a /21 for those customers.
> > 
> > This gets this sort of ISP into the hairy edge of what the 
> HD ratio allows in the best case.  Assuming a /48 assignment 
> to an end user counts as 100% utilization of the entire /48 
> subnet, then they will probably squeak through on the 
> Threshold (https://www.arin.net/policy/nrpm.html#six7).
> > 
> > And this discussion here is exactly why I originally 
> through out the question.  Why would an ISP assign a /48 so 
> that a consumer can have two large layers of subnetting (16 
> bits of subnet address to be exact) at the expense of their 
> own routing and summarization?
> > 
> > MW
> > 
> > 
> > Aaron Hughes wrote:
> > > US population is roughly 300 million.
> > > A /19 would cover 536,870,912 /48s
> > > A /27 would cover 536,870,912 /56s
> > > 
> > > 7 billion in the world.
> > > A /15 would cover 8,589,934,592 /48s A /23 would cover 
> 8,589,934,592 
> > > /56s.
> > > 
> > > Number of total Internet users in the world roughly 1.5 
> billion or 
> > > 20% of the population.
> > > Number of total Internet users in the US roughly 220 million.
> > > 
> > > Let's say you are Comcast.. ~ 25 million customers. Worst 
> cast you 
> > > are looking at a /23 to give each one a /48, or roughly 
> best case a 
> > > /39 for 2x/64s per customer.
> > > 
> > > This is not a repeat of v4.
> > > 
> > > IPv4 ISPs gave a single host to the outside interface of 
> the CPE AND 
> > > some flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12, 
> > > 192.168.0.0/16 for their inside interface.  If we 
> implement NAT in 
> > > v6, we will stop progress with end-to-end application development 
> > > and make the same silly mistakes we made with v4.  The 
> mistake was 
> > > not wasting space but rather not making the leap to IPv6 
> when we identified the potential for growth so many years ago.
> > > Instead we focused on CIDR/VLSM and NATing everything we could to 
> > > extend the life of a dying protocol.
> > > 
> > > It is perfectly reasonable to have standard assignment sizes to 
> > > create an appropriate customer expectation. Your customers do not 
> > > need to know what a subnet is.  If the standard was, for 
> example, to 
> > > assign a /64 to the WAN and /64 to the LAN with SLAAC 
> enabled, the 
> > > customer behaves the same way they do today.  Those who 
> request more 
> > > space know what they are doing (generally speaking).
> > > 
> > > Cheers,
> > > Aaron
> -- 
> 
> Aaron Hughes
> aaronh at bind.com
> (703) 244-0427
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C 
> C6 B8 http://www.bind.com/ 
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to 
> the ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
> 