Some advice on IPv6 planning and ARIN request, please

Fri Jul 7 17:15:00 UTC 2017

60 sites? Just ask for a /32.

/kc

On Fri, Jul 07, 2017 at 01:07:54PM -0400, Oliver O'Boyle said:
  >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

-- 
Ken Chase - math at sizone.org Guelph Canada