Some advice on IPv6 planning and ARIN request, please
math at sizone.org
Fri Jul 7 17:15:00 CST 2017
60 sites? Just ask for a /32.
On Fri, Jul 07, 2017 at 01:07:54PM -0400, Oliver O'Boyle said:
>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.
>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
>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
>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
>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,
Ken Chase - math at sizone.org Guelph Canada
More information about the NANOG