IPv6, multihoming, and customer allocations

Mailman List Mirror (Read Only)
1

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 and
a request for pointers if I'm rehashing an old question.

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 providers
for peering. Now, what do we do?

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 longest
prefix allowed through filters (although /49 through /54 are also
discussed). Most customers, however, won't be multi-homed.

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 with
special addressing like link-local if the hosts are not expected to be
internet reachable (back-end servervs, etc).

Based on the above, I'm looking to establish some initial policies to save
grief in the future:
- /52 allocations to end-users (residential, soho, etc.)
- /48 allocations to those that request it
- If you are going to multi-home, get your own space

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 me
at least, it seems reasonable for a first-pass.

For context/scope, we currently have the equivalent of a bit more than the
equivalent of a /16 (IPv4) in use.

Thanks,

2

https://www.arin.net/policy/nrpm.html#six541

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net

3

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 and
a 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 providers
for 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 longest
prefix allowed through filters (although /49 through /54 are also
discussed). Most customers, however, won't be multi-homed.

Generally, that's pretty accurate. Over time, I suspect the proportion of
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 with
special addressing like link-local if the hosts are not expected to be
internet reachable (back-end servervs, etc).

It isn't. Repeat after me... IPv6 addressing is vast and was designed to
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 save
grief 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 me
at least, it seems reasonable for a first-pass.

ARIN will accept you assigning anything up to a /48 to any end user. Anything
over a /48 requires a justification.

For context/scope, we currently have the equivalent of a bit more than the
equivalent of a /16 (IPv4) in use.

Then 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 /36
POPs would support roughly 4,000 customers. If you go to /40s, then, you
only get 200 customers per POP.

Hope this helps,

Owen

4

Regurgitating the original e-mail for context and follow-up.

General responses (some that didn't make it to the list):
  - "There really is that much space, don't worry about it."
  - /48s for those that ask for it is fine, ARIN won't ask unless it's a
bigger assignment
  - /52 (or /56) on smaller assignments for conservation if it makes you
feel better
  - Open question on whether byte/octet-boundary assignment (/56 vs /52) is
better for some reason

I haven't seen anything on the general feel for prefix filtering. I've seen
discussions from /48 down to /54. Any feel for what the "standard" (widely
deployed) IPv6 prefix filter size will be?

Thanks,

5

Rick Ernst wrote:
[..]

I haven't seen anything on the general feel for prefix filtering. I've seen
discussions from /48 down to /54. Any feel for what the "standard" (widely
deployed) IPv6 prefix filter size will be?

There have been a lot of discussions on this before.
(See also ipv6-ops Info Page)

1) IRR data, use whois.ripe.net to store also your non-RIPE, thus
   ARIN,APNIC etc details. This the best place to get your data.
   When a prefix is here, accept that size, clearly the ISP intends
   to distribute it that way.

2) Allocation size as given by the RIR(*), thus a /32 if the block is
   truly a /32 and a /48 when it is a /48.
   If you have PI that is PI, if you have PA it is Aggregated by you
   the provider, thus don't chop it up into little blocks.

3) Gert Doering's filter recommendations:
   http://www.space.net/~gert/RIPE/ipv6-filters.html

Also note that it is your network, accept/reject what you want.
Do remember the little problem that when you accept a /64 from some ISP,
that that prefix has to leak through a lot of little crappy holes to
actually get to you, it is a more specific, but the route might be
really really bad to get there.

As for the /48 vs /56 to end-user discussions, these prefixes are coming
out of PA space and thus should not exist in the DFZ. It is Provider
Aggregated, not PD (Provider Deaggregated) after all.

Greets,
Jeroen

* = Unfortunately it seems that ARIN is giving 1 entity prefixes spread
over multiple blocks, eg four distinct /32's; one can internally
aggregate those of course.

6

Regurgitating the original e-mail for context and follow-up.

General responses (some that didn't make it to the list):
- "There really is that much space, don't worry about it."
- /48s for those that ask for it is fine, ARIN won't ask unless it's a
bigger assignment
- /52 (or /56) on smaller assignments for conservation if it makes you
feel better
- Open question on whether byte/octet-boundary assignment (/56 vs /52) is
better for some reason

Octet boundary, not really. Nibble boundary, yes. Both for DNS delegation
convenience and for human factors issues.

I haven't seen anything on the general feel for prefix filtering. I've seen
discussions from /48 down to /54. Any feel for what the "standard" (widely
deployed) IPv6 prefix filter size will be?

So far, mostly it's /48 with a few select providers trying to hold the line at /32.

Owen

7

Regurgitating the original e-mail for context and follow-up.

General responses (some that didn't make it to the list):
  - "There really is that much space, don't worry about it."
  - /48s for those that ask for it is fine, ARIN won't ask unless it's a
bigger assignment
  - /52 (or /56) on smaller assignments for conservation if it makes you
feel better
  - Open question on whether byte/octet-boundary assignment (/56 vs /52) is
better for some reason

I haven't seen anything on the general feel for prefix filtering. I've seen
discussions from /48 down to /54. Any feel for what the "standard" (widely
deployed) IPv6 prefix filter size will be?

I filter at /48. I would consider filtering on something shorter for
assignments of /32 or shorter if there were obvious bad behaver's. We do
advertise more specific /36s but we also have the covering /32.

8

Regurgitating the original e-mail for context and follow-up.

General responses (some that didn't make it to the list):
  - "There really is that much space, don't worry about it."
  - /48s for those that ask for it is fine, ARIN won't ask unless it's a
bigger assignment
  - /52 (or /56) on smaller assignments for conservation if it makes you
feel better
  - Open question on whether byte/octet-boundary assignment (/56 vs /52) is
better for some reason

I haven't seen anything on the general feel for prefix filtering. I've seen
discussions from /48 down to /54. Any feel for what the "standard" (widely
deployed) IPv6 prefix filter size will be?

I filter at /48.

Although I'm small and insignificant, I do too.

I would consider filtering on something shorter for
assignments of /32 or shorter if there were obvious bad behaver's. We do
advertise more specific /36s but we also have the covering /32.

I think that it's going to filter down into a situation where people who
can allow a prefix might change their policy, given that the originator
is known. That doesn't mean that the next person in the chain will
accept it though.

For me, I'll accept /48's until one of two things happen:

- the RIRs decide that they won't be handing them out anymore
- that my routers can't handle the number of prefixes

Other than that, I'd like to see /48 become a standard for acceptance.

Steve

9

err... if the /48 was allocated/assigned from your local RIR from a
block that was originally designed for such purposes.

Otherwise, I don't blame anyone who is selective on filtering above /48
when the original alloc was /32 (or larger).

Steve