Re: Some advice on IPv6 planning and ARIN request, please

[Owen DeLong]

Oliver,

I’ll mostly second what Bill has said here. However, I encourage you to actually
consider a /48 per guest room as well as a /48 per hotel for the hotel itself.

Yes, this is excessive, but IPv6 was designed with these types of excesses in 
mind.

We don’t yet know the scope and breadth of what will come out of IoT 
development,
but one thing we do know for sure… Development tends to get stymied by whatever
turns into the lowest common denominator among available technologies out there,
so if 10 hotel chains give their guests /48s and 2 give out /60s and one gives
out /64s, development may well lock everyone into nothing better than what can
be done with a /64 even if better is available.

We’ve seen this time and again with products that depend on autodiscovery 
processes
that rely on everything being on the same LAN and assume that they can just 
trust
the NAT router to protect that LAN from anything else. This is clearly a very 
bad
strategy to anyone who understands networking, yet if you walk into your local
Best Buy, more of the “internet enabled” products on the shelf have this 
behavior
than don’t… Far more.

Owen

> On Jul 7, 2017, at 17:39 , Oliver O'Boyle  wrote:
> 
> Bill,
> 
> Thanks for the input. I don't consider us an isp, though i suppose i can
> see how that argument could me made. Hotels are both simple and
> complicated. There is a mix of our staff and equipment, guests and their
> equipment, and brands with their equipment. But really it's just one
> operating entity that ultimayely isn't that much different than any other
> enterprise out there. Now multiply that by 60-65 sites spread across the
> country and we need to manage our 6000 staff and networks accordingly. We
> operate 100% of the hotel, top to bottom, not just the technology.
> 
> I wouldn't want ARIN or anyone else thinking we were an ISP if we aren't.
> Particulary if that creates problems in the future as rules (and possibly
> costs) change.
> 
> However, if what you are saying is that registerong as an ISP is actually
> the correct way to go about this in ARIN's eyes as well, then that's a
> different story.
> 
> Thanks for the tip on IoT sizing. That's precisely the kind of thing i am
> concerned about being constrained with in the future if we size sites too
> small.
> 
> Oliver
> 
> On Jul 7, 2017 6:18 PM, "William Herrin"  wrote:
> 
> On Fri, Jul 7, 2017 at 1:07 PM, Oliver O'Boyle 
> wrote:
> 
>> 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.
> 
> 
> Hi Oliver,
> 
> I second Ken's notion. You're trying to be an ISP under the end-user rules.
> However transient, your users are mostly customers rather than staff. Just
> register as an ISP and get the default /32.
> 
> IIRC, ARIN sparsely allocates IPv6 so if you go back for more addresses
> there is a high probability they'll just increase your netmask.
> 
> Finally, /56 or /60 per guest, not /64. IPv6 can do nifty IoT things like
> collecting all of a guest's devices behind his personal firewall but it
> doesn't work if you've only assigned a /64.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> -- 
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 

Re: Some advice on IPv6 planning and ARIN request, please

[Oliver O'Boyle]

Bill,

Thanks for the input. I don't consider us an isp, though i suppose i can
see how that argument could me made. Hotels are both simple and
complicated. There is a mix of our staff and equipment, guests and their
equipment, and brands with their equipment. But really it's just one
operating entity that ultimayely isn't that much different than any other
enterprise out there. Now multiply that by 60-65 sites spread across the
country and we need to manage our 6000 staff and networks accordingly. We
operate 100% of the hotel, top to bottom, not just the technology.

I wouldn't want ARIN or anyone else thinking we were an ISP if we aren't.
Particulary if that creates problems in the future as rules (and possibly
costs) change.

However, if what you are saying is that registerong as an ISP is actually
the correct way to go about this in ARIN's eyes as well, then that's a
different story.

Thanks for the tip on IoT sizing. That's precisely the kind of thing i am
concerned about being constrained with in the future if we size sites too
small.

Oliver

On Jul 7, 2017 6:18 PM, "William Herrin"  wrote:

On Fri, Jul 7, 2017 at 1:07 PM, Oliver O'Boyle 
wrote:

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


Hi Oliver,

I second Ken's notion. You're trying to be an ISP under the end-user rules.
However transient, your users are mostly customers rather than staff. Just
register as an ISP and get the default /32.

IIRC, ARIN sparsely allocates IPv6 so if you go back for more addresses
there is a high probability they'll just increase your netmask.

Finally, /56 or /60 per guest, not /64. IPv6 can do nifty IoT things like
collecting all of a guest's devices behind his personal firewall but it
doesn't work if you've only assigned a /64.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Some advice on IPv6 planning and ARIN request, please

[William Herrin]

On Fri, Jul 7, 2017 at 1:07 PM, Oliver O'Boyle 
wrote:

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


Hi Oliver,

I second Ken's notion. You're trying to be an ISP under the end-user rules.
However transient, your users are mostly customers rather than staff. Just
register as an ISP and get the default /32.

IIRC, ARIN sparsely allocates IPv6 so if you go back for more addresses
there is a high probability they'll just increase your netmask.

Finally, /56 or /60 per guest, not /64. IPv6 can do nifty IoT things like
collecting all of a guest's devices behind his personal firewall but it
doesn't work if you've only assigned a /64.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: Some advice on IPv6 planning and ARIN request, please

[Oliver O'Boyle]

Thanks, Jima. I'll review the slides.

Without complicating the issue, we're trying to address a number of
challenges at the same time. There's no regional backhauling at this time.
Each site will be reachable via the internal network but will also
independently announce it's assignment to its ISP(s). There are many
reasons for this model, some of which I like and others I don't! We do plan
to coordinate address assignments/aggregations with the ISPs to reduce
global routes and unwanted conflicts/overlap.Unfortunately, there's no real
hub in each region and the ISPs are not region-specific. We inherit a bunch
of stuff and then need to find a way to jam it into something that isn't
completely broken... we've done a lot of cleanup and re-org of services but
there's still a long way to go. IPv6 should help us get there, however.

Agreed with the /48 but ARIN doesn't appear to agree with our justification
for a /36 thus far.


On Fri, Jul 7, 2017 at 1:33 PM, Jima  wrote:

> On 2017-07-07 11:07, Oliver O'Boyle wrote:
>
>> 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.
>>
>
> If you're backhauling each region (even effectively via your upstream),
> I'd take a look/listen to these two slides: https://www.youtube.com/watch?
> v=rWJZfShWE6g=12m46s (Honestly, that entire video is worth watching if
> you're preparing to make your initial IPv6 PI space request -- it's a very
> informative presentation, and is fairly authoritative.)
>
> Net-net, if "hub 1" is supporting 30-ish sites, with projected growth to
> 46-ish, you could possibly make the case for allocating a /40 per hub, and
> a /38 (or maybe even /36) overall. (There's only one /38 assignment in ARIN
> region, FWIW.)
>
> 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.
>>
>
> If it's a site, /48 is justified as per ARIN requirements, period.
>
> 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.
>>
>
> Might. I'd file the request, as long as you have a logical addressing plan
> to justify it.
>
>  Jima
>



-- 
:o@>

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
MENOG, SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 08 Jul, 2017

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  653872
Prefixes after maximum aggregation (per Origin AS):  254333
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  315298
Total ASes present in the Internet Routing Table: 57740
Prefixes per ASN: 11.32
Origin-only ASes present in the Internet Routing Table:   49962
Origin ASes announcing only one prefix:   22072
Transit ASes present in the Internet Routing Table:7778
Transit-only ASes present in the Internet Routing Table:223
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  54
Max AS path prepend of ASN ( 55644)  51
Prefixes from unregistered ASNs in the Routing Table:60
Numnber of instances of unregistered ASNs:   64
Number of 32-bit ASNs allocated by the RIRs:  19359
Number of 32-bit ASNs visible in the Routing Table:   15061
Prefixes from 32-bit ASNs in the Routing Table:   61319
Number of bogon 32-bit ASNs visible in the Routing Table:64
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:349
Number of addresses announced to Internet:   2848140388
Equivalent to 169 /8s, 195 /16s and 44 /24s
Percentage of available address space announced:   76.9
Percentage of allocated address space announced:   76.9
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.7
Total number of prefixes smaller than registry allocations:  217691

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   179377
Total APNIC prefixes after maximum aggregation:   51366
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  178434
Unique aggregates announced from the APNIC address blocks:73877
APNIC Region origin ASes present in the Internet Routing Table:8227
APNIC Prefixes per ASN:   21.69
APNIC Region origin ASes announcing only one prefix:   2309
APNIC Region transit ASes present in the Internet Routing Table:   1163
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3071
Number of APNIC addresses announced to Internet:  763514212
Equivalent to 45 /8s, 130 /16s and 77 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:199057
Total ARIN prefixes after maximum aggregation:94804
ARIN Deaggregation factor: 2.10
Prefixes being announced from the ARIN address blocks:   201014
Unique aggregates announced from the ARIN address blocks: 92372
ARIN Region origin ASes present in the Internet Routing Table:17915
ARIN Prefixes per ASN:

Re: Some advice on IPv6 planning and ARIN request, please

[Jima]

On 2017-07-07 11:07, Oliver O'Boyle wrote:

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.


If you're backhauling each region (even effectively via your upstream), 
I'd take a look/listen to these two slides: 
https://www.youtube.com/watch?v=rWJZfShWE6g=12m46s (Honestly, that 
entire video is worth watching if you're preparing to make your initial 
IPv6 PI space request -- it's a very informative presentation, and is 
fairly authoritative.)


Net-net, if "hub 1" is supporting 30-ish sites, with projected growth to 
46-ish, you could possibly make the case for allocating a /40 per hub, 
and a /38 (or maybe even /36) overall. (There's only one /38 assignment 
in ARIN region, FWIW.)



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.


If it's a site, /48 is justified as per ARIN requirements, period.


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.


Might. I'd file the request, as long as you have a logical addressing 
plan to justify it.


 Jima

Re: Some advice on IPv6 planning and ARIN request, please

[Ken Chase]

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 - m...@sizone.org Guelph Canada

Some advice on IPv6 planning and ARIN request, please

[Oliver O'Boyle]

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

Re: EdgeRouter Infinity as medium-sized "IXP Peering Router"?

[Jérôme Nicolle]

Hello Jeremy,

Le 04/07/2017 à 01:10, Jeremy Austin a écrit :
> can certainly handle a few tens of thousands of
> routes fine (single core BGP though), 

It can take multiple full views. It's also faster than an MX104.

> but I can't vouch for its ability to
> do IMIX or *flow at line rate

I wouldn't load one to 80g, but at 10-20G, it creates no bottleneck.

The entire packet-pipeline is in software. IPFIX is not sampled, it's
1:1 only AFAIK. It's also lacking some features, meaning you'd need to
filter through pmacct to add BGP informations.

Best regards,

-- 
Jérôme Nicolle