Some advice on IPv6 planning and ARIN request, please

Lee Howard lee at asgard.org
Sat Jul 8 16:01:30 UTC 2017



On 7/7/17, 1:07 PM, "NANOG on behalf of Oliver O'Boyle"
<nanog-bounces at nanog.org on behalf of oliver.oboyle at gmail.com> wrote:

> We're currently in the planning stage and can make
>whatever changes we need to.

I always say to just expect you’ll change your address plan three times.
Some people say, “I’ve only changed the address plan twice. . . so far.”

>
>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.

Even assuming, as you said: a /48 per hotel, it sounds like you’re
planning for:
Region A, 45 sites, minimum /42
Region B, <20 sites, minimum /44
Region C, <20 sites, minimum /44
Cloud stuff, minimum /48, but that might need more

However, as others have suggested, you might want to start from the
bottom, deciding the allocations within each hotel. It may be that you
need multiple /48s for HotelGuest, HotelLobby, HotelConference, and
HotelStaff SSIDs. 
A /64 per WiFi AP is an aboslute minimum, but a prefix per room (or guest)
would be better, and there are reasons to consider /56 and /48 per “end
user” in the hotel. Even if you can’t assign it with current WiFi
technology, your address plan should allow for an evolution to a better
way of doing things.
If my math works right, and you have between 127 and 255 rooms in a hotel:
255 * /56 = /48 just for HotelGuest. You may need a /44 per hotel, if
there are four separate networks.
Or:
255 * /48 = /40 just for HotelGuest. You may need a /36 per hotel.

As others have said, I’m assuming you treat guests to whom you provide
Internet service as customers.


>
>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.

Try calling ARIN. Ask a hostmaster whether the End User or ISP category
makes more sense in your case. It’s also possible they’ll say “slow start”
and give you a /40 for your first hotel, and tell you to return in a week
when you need more.

But also, take into account [NRPM 6.5.8.2] "Requests for            larger
initial assignments, reasonably justified with supporting
documentation, will be evaluated based on the number of sites in an
    organization’s network and the number of subnets needed to support any
           extra-large sites defined below.” There’s a lot of room within
policy to do sensible things with IPv6.

>
>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

Yes, all good goals. But none is critical to the success of your network
(except c, only if you plan to delegate reverse DNS). “As much as
possible” also implies “and no more than is possible.”

>
>Thanks in advance,
>Oliver


btw, I can’t wait to stay in your hotels once they have IPv6! I hope
you’ll be able to tweet or post here when it’s deployed, so we can
congratulate you, and maybe get some conferences to consider you as a
venue.

Lee






More information about the NANOG mailing list