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