Some advice on IPv6 planning and ARIN request, please

Fri Jul 7 17:07:54 UTC 2017

Hello,

If anyone out there could provide some input or advice on how to best
handle our upcoming leap into IPv6, it would be much appreciated. I want to
make sure we're playing nicely and not causing anyone any unnecessary grief
before we deploy. We're currently in the planning stage and can make
whatever changes we need to.

Situation:

We're an end-user org and qualify for a /40 assignment because we operate
over 60 sites and some of those are/will be multihomed. We manage hotels in
Canada only, but from coast to coast to coast and everywhere in between.
Our corporate network and org structure is optimized for three regions. We
also have, and continue to grow into, cloud infrastructure and foresee
wanting to bring our own addresses (.e.g., to AWS VPC when that option
becomes available). As such, an obvious design strategy would be to break
the /40 into 4 x /42's. However, due to an imbalance in national site
distribution, 50% of our sites are located in one region (Region A).
Additionally, historical and forecasted growth indicates that it's
perfectly reasonable for us to expect growth of an additional 16 sites in
that same region over the next 3-5 years.

We would prefer to summarize at the /42 level, announced from our last-mile
providers. There are 3 primary last-mile providers so this strategy would
help significantly reduce the number of global routes being injected. If we
split regions evenly at /42 and if we follow the /48-per-site best practice
(which I believe is justifiable in our situation - see below), Region A
will be at 50% usage immediately. Adding 16 more sites brings it to 75%
usage in only a few years. The other regions would be at ~33% usage (Region
B) and 15% usage (Region C) and will see moderate growth in 3-5 years.
Cloud will initially be at 2-4% usage (Region D) but will also grow quickly
within 3-5 years.

Ideal situation: ARIN assigns us a /36 and we don't need to worry about
re-addressing. Even if they can offer us contiguous space with a second
request to increase our assignment, we would likely need to re-address a
significant portion of our sites which would be painful and time-consuming.
Less ideal situation #1: Split the first level of subnets unevenly at 1 x
/41 and 2 x /42 and hope we can carve out some of that space for use in our
cloud infrastructure. This strategy would solve our Region A problem and
would keep Regions B and C from going to 68% and 34% utilization
immediately but it would mess up Region D and impact Regions B and C.
Less ideal situation #2: Split the first level of subnets unevenly at 1 x
/41, 1 x /42, and 2 x /43. This strategy would solve our Region A and
Region B problems but would constrain Region C and Region D future growth
options somewhat.
Less ideal situation #3: Drop the /48 per site default to somewhere between
a /49 and /53 and hope we don't bust out of those. This strategy would
allow us to keep top-level aggregation at /42's but would move the site
assignments off the nibble boundaries.
Less ideal situation #4: Keep 4 x /42's and hope we don't expand out of
them in Region A. This strategy would imply we don't wish for our business
to grow and is pretty risky.

I feel the /48 site default is justifiable because of the various
applications and services that are currently, or could likely be offered at
hotels. E.g., each room gets a /64 for all guest-internet devices
registered to that room. + IoT could result in the same rule (each room
gets a /64) or, perhaps a bit simpler, each class of IoT device is on a /64
or each IoT vendor is on a /64. There will also be new applications that
come out with similar possible needs. With some of our hotels in the
500-1000 room range, we're looking at as many as 2000 /64's per site in the
next 5 or so years. Plus backoffice/admin subnets.

I think the ideal situation is out as ARIN policy wouldn't allow them to
assign us a /36 at this time. Unless someone knows something that can help
us here.

Assuming we can't get a /36, my feeling is that less ideal situation #2 is
better than #3 is better than #1 is better than #4, assuming we're
following the following design best-practices:

a) assign top-level aggregations evenly (which we'd be breaking a bit with
option #2)
b) reduce global routes as much as possible
c) stay on the nibble boundary as much as possible
d) default to /48 per site

Any thoughts or advice would be much appreciated.

Thanks in advance,
Oliver