ISP customer assignments

Brian Johnson bjohnson at drtel.com
Mon Oct 5 18:10:15 UTC 2009


What would be "wrong" with using a /64 for a customer who only has a
local network? Most home users won't understand what a subnet is.

- Brian


> -----Original Message-----
> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of
William
> Herrin
> Sent: Monday, October 05, 2009 11:58 AM
> To: Brian Johnson
> Cc: nanog at nanog.org
> Subject: Re: ISP customer assignments
> 
> On Mon, Oct 5, 2009 at 11:27 AM, Brian Johnson <bjohnson at drtel.com>
> wrote:
> > From what I can tell from an ISP perspective, the design of IPv6 is
> for
> > assignment of a /64 to an end user. Is this correct? Is this how it
> is
> > currently being done? If not, where am I going wrong?
> 
> No. A /64 is one *subnet*. Essentially the standard, static size for
> any Ethernet LAN. For a customer, the following values are more
> appropriate:
> 
> /128 - connecting exactly one computer. Probably only useful for your
> dynamic dialup customers. Any always-on or static-IP customer should
> probably have a CIDR block.
> 
> /48 - current ARIN/IETF recommendation for a downstream customer
> connecting more than one computer unless that customer is large enough
> to need more than 65k LANs.
> 
> /56 - in some folks opinion, slightly more sane than assigning a 65k
> subnets and bazillions of addresses to a home hobbyist with half a
> dozen PC's.
> 
> /60 - the smallest amount you should allocate to a downstream customer
> with more than one computer. Anything smaller will cost you extra
> management overhead from not matching the nibble boundary for RDNS
> delegation, handling multiple routes when the customer grows, not
> matching the standard /64 subnet size and a myriad other obscure
> issues.
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
> 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
> Falls Church, VA 22042-3004




More information about the NANOG mailing list