nanog mailing list archives
Re: IPv6, multihoming, and customer allocations
From: Owen DeLong <owen () delong com>
Date: Sat, 13 Mar 2010 23:49:58 -0800
On Mar 13, 2010, at 9:49 PM, Rick Ernst wrote:
A couple of different incantations searching the archive didn't enlighten me, and I find it hard to believe this hasn't been discussed. Apologies anda request for pointers if I'm rehashing an old question.
Don't have the pointers handy, but, it has been discussed as well as the meta-discussion of the general lack of BCP and documentation available. One good source for some information is http://www.getipv6.info
As a small/regional ISP, we got our /32 assigned and it's time to start moving forward (customers are asking for it). New hardware, updated IOS, etc. are in the pipe. Discussions are beginning with our upstream providersfor peering. Now, what do we do?
Glad to hear customers are asking for it. That's a good sign. I think the next step is to start planning your address utilization.Some ISPs are giving all customers a /48. Some are giving small (residential, SOHO, and small business) a /56 by default and a /48 on request. A /48 is given to each site of medium-to-large businesses, more with proper justification.
A /48 seems to be the standard end-user/multi-homed customer allocation and is the minimum allocation size from ARIN. A /32 provides 65K /48s so, in theory, we could give each of our customers a /48 and still have room for growth. A /48 also appears to be generally accepted as the the longestGenerally, that's pretty accurate. Over time, I suspect the proportion ofprefix allowed through filters (although /49 through /54 are also discussed). Most customers, however, won't be multi-homed.
multihomed customers will increase.
Partly from an IPv4 scarcity perspective, and partly from general efficiency and thrift, it seems awfully silly to hand out /48s to somebody that may have a handful of servers or a couple of home machines, especially withIt isn't. Repeat after me... IPv6 addressing is vast and was designed tospecial addressing like link-local if the hosts are not expected to be internet reachable (back-end servervs, etc).
allow sparse allocations. It is not necessary to conserve every singe address.
Based on the above, I'm looking to establish some initial policies to savegrief in the future: - /52 allocations to end-users (residential, soho, etc.)
/52 works, too, although most people who are doing less than /48 are going
to /56, with /48 as the fallback if /56 is not enough.
- /48 allocations to those that request it
Good plan.
- If you are going to multi-home, get your own space
Not necessarily. There are still many multihoming scenarios that do not meet the ARIN criteria for provider-independent address assignment. As much as I would like to change the ARIN criteria, for now, the community seems to feel that there is concern about overflowing the capabilities of backbone routers if we did this.
This is obviously a very broad brush and takes an insanely large addressing model and makes it even larger (assigning /52s instead of /48s) but, to meARIN will accept you assigning anything up to a /48 to any end user. Anythingat least, it seems reasonable for a first-pass.
over a /48 requires a justification.
For context/scope, we currently have the equivalent of a bit more than theThen your /32 may very likely be enough for you for IPv6. Something to consider, if you have multiple POPs or locations, you may want to enable aggregation of those locations on nibble boundaries. Doing so means that you could do 16 POPs with a /36 each, or, 256 POPs with a /40 each. Each of the 16 /36equivalent of a /16 (IPv4) in use.
POPs would support roughly 4,000 customers. If you go to /40s, then, you only get 200 customers per POP. Hope this helps, Owen
Current thread:
- IPv6, multihoming, and customer allocations Rick Ernst (Mar 13)
- Re: IPv6, multihoming, and customer allocations Antonio Querubin (Mar 13)
- Re: IPv6, multihoming, and customer allocations Owen DeLong (Mar 13)
- Re: IPv6, multihoming, and customer allocations Rick Ernst (Mar 16)
- IPv6 filtering practices (Was: IPv6, multihoming, and customer allocations) Jeroen Massar (Mar 16)
- Re: IPv6, multihoming, and customer allocations Owen DeLong (Mar 16)
- Re: IPv6, multihoming, and customer allocations Joel Jaeggli (Mar 16)
- Re: IPv6, multihoming, and customer allocations Steve Bertrand (Mar 16)
- Re: IPv6, multihoming, and customer allocations Steve Bertrand (Mar 16)
