[arin-discuss] IPv6 End User Assignments

Wed May 6 17:24:08 EDT 2009

On Wed, May 06, 2009 at 01:37:33PM -0700, Ted Mittelstaedt wrote:
> 
> Aaron,
> 
>   Was space-wasting the only reason you went with a /64 instead of
> a /48 or /56?

Yes.

>   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?  

/64 was for any customer with one broadcast domain, 1 to several machines.  If they have multiple broadcast domains (more than one), they get a 48. 56 vs 64 was just a flip a coin decision to some extent.  There was a ton of discussion on the topic and I just picked one and moved forward.  At some point you just have to implement and get some real world experience.

I did look at assigning something smaller than a 64 initially and tools turned out to be the deciding factor.  Since all of my v4 tools such as allocations/assignments/router config/CRM/ERP/etc store the v4 address as 4 x INT(11), it was rather easy to convert hex to dec and store in the same tables.  The mask in this case is also an INT(11).  Adding the additional octets would have been much more effort.

> Do you consider a customer
> who has a wireless router with 5-6 PC's on it as needing a subnet
> ie /48?

No.  a 64 should be fine for that kind of customer assuming all the objects are in the same broadcast domain (e.g. bridged mode on the wireless router).

Cheers,
Aaron

> 
> 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.
> > 

-- 

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/