Re: IPv6 traffic percentages?

[Jima]

On 2017-06-23 09:09, Lee Howard wrote:

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.


Speaking with my Enterprise Day Job hat on...

I started doing analytics on IPv6 client support regarding a (currently 
IPv4-only) employee-facing web app my team hosts. Turns out that in 15% 
of connections with IPv6, the IPv4 is coming from a subsidiary VPN, but 
the IPv6 isn't VPN'd -- supporting your point. (That number may be 
artificially low, in that not all of our business units restrict the 
users' source IP.)



d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.


When you get big enough (and go through enough mergers & acquisitions), 
RFC1918 runout becomes a serious, legitimate concern. That's been a big 
selling point for me.


 Jima

Re: IPv6 traffic percentages?

[Rod Beck]

The RIPE lab tests don't indicate any compelling network performance edge for 
IPV6. https://labs.ripe.net/Members/gih/examining-ipv6-performance. Large 
businesses have huge sunk costs in their existing infrastructure. Top it off 
with conservative bureaucratic mentalities and it is pretty clear why they 
avoid IPV4.


From: NANOG  on behalf of Lee Howard 
Sent: Friday, June 23, 2017 5:09:23 PM
To: Radu-Adrian Feurdean; Mukom Akong T.
Cc: NANOG list
Subject: Re: IPv6 traffic percentages?



On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean"

wrote:

>On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
>>
>> On 18 June 2017 at 17:36, Radu-Adrian Feurdean > adrian.feurdean.net> wrote:>> so for the record, business customers are
>>much more active in
>>>  *rejecting* IPv6, either explictely (they say they want it
>>>  disabled) or>>  implicitly (they install their own router, not
>>>configured for
>>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
>>
>>
>> Did they per chance state their reasons for rejecting it?
>
>Not explicitly. But when we get something like "turn off that IPv6 crap
>!" we take it for: - they don't have a clearly defined need for it
> - they don't know how to deal with it
> - they don't want to deal with things they don't need (see the
>   irst point)... usually all of them at the same time.

That is my experience, too. When I was in IT, my response was to block
IPv6 at the firewall (until I learned my firewall was incapable of
examining IPv6 packets and therefore allowed ALL IPv6; I wasn’t allowed to
change firewalls so I used a router ACL to block it while I reviewed our
IPv6 security policy and looked for another job). When I was at an ISP, we
could route IPv6 to the customer, but until they enabled it, no traffic
would follow.

>
>To make it short : education. And we as as small ISP we have neither the
>resources, nor the motivation (because $$$ on the issue is negative) to
>do it (the education).

I think you’re talking about business education, not technical IPv6
education, right?
I recently posted my suggested technical reading list:
http://www.wleecoyote.com/blog/IPv6reading.html

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
   a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.
   b. Lower latency.
   c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit
masking, IPv6 address as process ID.
   d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.
http://www.wleecoyote.com/blog/2017prices.htm

2. Enterprise IPv6 implementation guidance
  a. https://tools.ietf.org/html/rfc7381  “Enterprise IPv6 Deployment
Guidelines”
  b. Cost to Renumber and Sell IPv4
http://retevia.net/Downloads/EnterpriseRenumbering.pdf


I’ll see if I can write up #1 into a single paper or blog post in the next
few days. Anything else I should add?

Lee

>

Re: IPv6 traffic percentages?

[Lee Howard]

On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean"

wrote:

>On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
>> 
>> On 18 June 2017 at 17:36, Radu-Adrian Feurdean > adrian.feurdean.net> wrote:>> so for the record, business customers are
>>much more active in
>>>  *rejecting* IPv6, either explictely (they say they want it
>>>  disabled) or>>  implicitly (they install their own router, not
>>>configured for
>>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
>> 
>> 
>> Did they per chance state their reasons for rejecting it?
>
>Not explicitly. But when we get something like "turn off that IPv6 crap
>!" we take it for: - they don't have a clearly defined need for it
> - they don't know how to deal with it
> - they don't want to deal with things they don't need (see the
>   irst point)... usually all of them at the same time.

That is my experience, too. When I was in IT, my response was to block
IPv6 at the firewall (until I learned my firewall was incapable of
examining IPv6 packets and therefore allowed ALL IPv6; I wasn’t allowed to
change firewalls so I used a router ACL to block it while I reviewed our
IPv6 security policy and looked for another job). When I was at an ISP, we
could route IPv6 to the customer, but until they enabled it, no traffic
would follow.

>
>To make it short : education. And we as as small ISP we have neither the
>resources, nor the motivation (because $$$ on the issue is negative) to
>do it (the education).

I think you’re talking about business education, not technical IPv6
education, right?
I recently posted my suggested technical reading list:
http://www.wleecoyote.com/blog/IPv6reading.html

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
   a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.
   b. Lower latency.
   c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit
masking, IPv6 address as process ID.
   d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.
http://www.wleecoyote.com/blog/2017prices.htm

2. Enterprise IPv6 implementation guidance
  a. https://tools.ietf.org/html/rfc7381  “Enterprise IPv6 Deployment
Guidelines” 
  b. Cost to Renumber and Sell IPv4
http://retevia.net/Downloads/EnterpriseRenumbering.pdf


I’ll see if I can write up #1 into a single paper or blog post in the next
few days. Anything else I should add?

Lee

>

Re: Long AS Path

[Ryan L]

I didn't see anyone answer (sorry if I missed it and this is redundant) ...

In the path selection algorithm, local preference is processed before
AS-PATH.

Within your provider's AS, your prefixes could be a default localpref of
100, and learned prefixes from their peers 85, for example. In this case,
Intra-AS will always be preferred due to higher lpref.

You may prepend a handful of times out of your connection that is within
the provider's AS, thus making the overall AS-PATH longer, but localpref
still remains 100 vs. peer 85, so intra-AS still preferred.

Some providers allow you to send community attributes with your prefixes to
modify the localpref within the provider AS and make it lower than their
peer localpref. Solves this particular conundrum.

Couple examples:

https://onestep.net/communities/as3356/
https://onestep.net/communities/as1299/

Depending on your allocation size and your needs, if you wanted to force
all traffic over the "fast" link and use the "slow" link as an emergency
backup, it could be easier to just announce more specific routes out the
faster connection and send an aggregate out the backup one. No communities
needed in that scenario. All depends on what you need to do, of course.

HTH,
Ryan


On Thu, Jun 22, 2017 at 9:29 AM, Stephen Satchell  wrote:

> On 06/22/2017 04:27 AM, Jon Lewis wrote:
> >
> > You do have to wonder, what was the thought process that resulted in 35
> > being the right number of prepends "accomplish" whatever TE they were
> > shooting for?
> >
> > AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644
> > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
> > 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644
> > 55644 55644 55644 45271
> >
> > I don't mean to single out 55644.  It's just the first/most obnoxiously
> > long as-path I found when looking for long ones.
> >
> > I seriously doubt provider/customer/customer-of-customer relationships
> > ever get much deeper than a handful or so of ASNs...so if prepending a
> > few times doesn't get it done, 10-20-30 prepends are unlikely to help.
> >
> > In the above case, that long path is actually our best path.  We
> > localpref peering above transit.  So, it doesn't matter how many
> > prepends, they add, we're never going to not use this path if its
> > available.  We have transit paths to these routes that are only a single
> > handful of ASNs long.
>
>
> I think I understand the problem, and now I understand why prepends
> didn't do much for me.  Over the years, I tended two multi-homed sites.
> In both cases, the two uplinks had different speeds.  When I used
> prepend to try to get the outside world to prefer the faster link, some
> traffic was stubborn about coming in the slow one.
>
> Difference in speeds?  In the first network it was 45 mbps and 10 mbps.
> In the second network it was 16 mbps and 1.5 mbps.  Both network owners
> were too stingy at the time to opt for harmonized rates.
>
> Question:  how could communities be used to "force" preference for one
> uplink over another by the peers?  I'm long past needing this, but
> others might benefit.  (And when you stop learning, you're dead.)
>

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 24 Jun, 2017

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

Analysis Summary


BGP routing table entries examined:  652252
Prefixes after maximum aggregation (per Origin AS):  253804
Deaggregation factor:  2.57
Unique aggregates announced (without unneeded subnets):  314199
Total ASes present in the Internet Routing Table: 57616
Prefixes per ASN: 11.32
Origin-only ASes present in the Internet Routing Table:   49870
Origin ASes announcing only one prefix:   22007
Transit ASes present in the Internet Routing Table:7746
Transit-only ASes present in the Internet Routing Table:221
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  41
Max AS path prepend of ASN ( 55644)  36
Prefixes from unregistered ASNs in the Routing Table:50
Numnber of instances of unregistered ASNs:   54
Number of 32-bit ASNs allocated by the RIRs:  19170
Number of 32-bit ASNs visible in the Routing Table:   14928
Prefixes from 32-bit ASNs in the Routing Table:   60687
Number of bogon 32-bit ASNs visible in the Routing Table:62
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:365
Number of addresses announced to Internet:   2850215268
Equivalent to 169 /8s, 226 /16s and 213 /24s
Percentage of available address space announced:   77.0
Percentage of allocated address space announced:   77.0
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:  217120

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   178941
Total APNIC prefixes after maximum aggregation:   51343
APNIC Deaggregation factor:3.49
Prefixes being announced from the APNIC address blocks:  178085
Unique aggregates announced from the APNIC address blocks:73610
APNIC Region origin ASes present in the Internet Routing Table:8215
APNIC Prefixes per ASN:   21.68
APNIC Region origin ASes announcing only one prefix:   2309
APNIC Region transit ASes present in the Internet Routing Table:   1158
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 41
Number of APNIC region 32-bit ASNs visible in the Routing Table:   3044
Number of APNIC addresses announced to Internet:  763609444
Equivalent to 45 /8s, 131 /16s and 193 /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:198554
Total ARIN prefixes after maximum aggregation:94628
ARIN Deaggregation factor: 2.10
Prefixes being announced from the ARIN address blocks:   200377
Unique aggregates announced from the ARIN address blocks: 92081
ARIN Region origin ASes present in the Internet Routing Table:17909
ARIN Prefixes per ASN:  

Re: Long AS Path

[Mel Beckman]

James, 

The question is whether you would actually hear of any problems. Chances are 
that the problem would be experienced by somebody else, who has no idea that 
your filtering was causing it. 

 -mel beckman

> On Jun 23, 2017, at 4:33 AM, James Bensley  wrote:
> 
> On 21 Jun 2017 17:51, "Mel Beckman"  wrote:
> 
> Steinar,
> 
> What reason is there to filter them?
> 
> 
> The main reason I know of is this:
> 
> On 22 Jun 2017 17:17, "Steve Lalonde"  wrote:
> 
> Mel,
> 
> There was a Cisco bug many years ago that caused lots of issues. Since then
> we have limited max-as to 50 and it has not caused any reported issues yet.
> 
> Link that does not require a CCO login to view.
> http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html
> 
> 
> Like many providers we do still have legacy kit tucked away with shameful
> firmware versions running and also multiple vendors in play so I can't be
> sure we don't have devices still susceptible to such a bug in view of the
> DFZ.
> 
> On 21 Jun 2017 18:45, "Bob Evans"  wrote:
> 
> My cut off is 6 ASNs - more than 6 and it never makes it to the FIB.
> 
> 
> So for the above reason we do have an AS_PATH limit but it is quite high
> like 63 or 120 ASNs (on mobile can't remember and right now). I don't want
> to get near a ^2 boundary like 255 or 128 but also don't want to drop
> prefixes if possible like a last resort fail-safe, so it's a very high
> number and will remove it at some point.
> 
> On 22 Jun 2017 14:49, "jim deleskie"  wrote:
> 
> I see 5+ prepends as maybe not reason to have your "BGP driving license
> revoked" but if I can continue with the concept that you have your BGP
> learners permit.
> 
> 
> That (6) seems pretty low to me. Apart from a potential bug the other
> reason we thought of to block routes with a massive AS_PATH is that it
> could be a sign that the operator of a network doesn't know what their
> doing or doesn't have good processes in place (YMMV). If you have a path
> twice in BGP, once with a "giant" path length and once with a "normal"
> length the provider offering the "longer" path may have any manner of
> problems internally if they can't even manage their BGP routing policies
> appropriately.
> 
> I have seen genuine reasons for up to about 6 pre-prends and beyond so
> you're probably dropping a decent amount of routes. At the time I set our
> filter I think we were dropping one single route. No one has complained so
> its still in place.
> 
> Giant AS_PATHs can be debated in a similar fashion to AS numbers
> used/restricted by RFCs. We have AS number filters in place to block
> prefixes with a private ASN in the path, any transit provider should block
> such routes, again if they aren't it's a sign to me they're not doing a
> really great job. But it's very hard to know if you can drop those routes
> without affecting your customer base or that a suitable alternative exists.
> Great care must be taken when doing this.
> 
> Otherwise the following issue arises:
> 
> On 21 Jun 2017 19:13, "Saku Ytti"  wrote:
> 
> Hey,
> 
> Uou're saying, you drop long AS_PATH, to improve customer observed
> latency? Implication being, because you dropped the long AS_PATH
> prefixes, you're now selecting shorter AS_PATH prefixes to the FIB?
> 
> Absent of this policy, in which scenario would you have inserted the
> filtered longer AS_PATH prefix to the FIB? I assume only scenario
> where this happens is where there is larger aggregate route, which is
> lower latency than the more specific route with longer as_path.
> 
> 
> So we drop "giant" AS_PATH length routes and routes with certain ASNs in
> the path, but we are fairly certain we don't need them / our customers
> don't need them etc. Not because we believe we are getting better (lower
> latency routes) routes from somewhere else as Saku said above, we can't
> feasibly "test" and compare the performance of every route we receive or
> need/want, but to protect our infrastructure.
> 
> On 22 Jun 2017 16:54, "Jakob Heitz (jheitz)"  wrote:
> 
> 23456 is AS_TRANS. Either your router does not support 4 byte AS or there
> is a bug at AS 12956 or AS 12956 is intentionally prepending 23456.
> 
> 
> This ties in with my point about specific ASN filtering. Its not a problem
> seeing 23456 in your table but again perhaps an indicator of a problem or
> someone using legacy kit. No problem with 23456 routes like AS_PATH length
> of up to say 50 but beyond that, I can't thing of a genuine reasons and
> could be a sign that along the path there may be stability issues for
> example. Again, too difficult to measure.
> 
> Depending on your customer base and requirements it can be safe to drop
> giant paths but care is needed, and if you do it, I think a number like 6
> is way too low.
> 
> Cheers,
> James.

Re: Long AS Path

[James Bensley]

On 21 Jun 2017 17:51, "Mel Beckman"  wrote:

Steinar,

What reason is there to filter them?


The main reason I know of is this:

On 22 Jun 2017 17:17, "Steve Lalonde"  wrote:

Mel,

There was a Cisco bug many years ago that caused lots of issues. Since then
we have limited max-as to 50 and it has not caused any reported issues yet.

Link that does not require a CCO login to view.
http://blog.ipspace.net/2009/02/oversized-as-paths-cisco-ios-bug.html


Like many providers we do still have legacy kit tucked away with shameful
firmware versions running and also multiple vendors in play so I can't be
sure we don't have devices still susceptible to such a bug in view of the
DFZ.

On 21 Jun 2017 18:45, "Bob Evans"  wrote:

My cut off is 6 ASNs - more than 6 and it never makes it to the FIB.


So for the above reason we do have an AS_PATH limit but it is quite high
like 63 or 120 ASNs (on mobile can't remember and right now). I don't want
to get near a ^2 boundary like 255 or 128 but also don't want to drop
prefixes if possible like a last resort fail-safe, so it's a very high
number and will remove it at some point.

On 22 Jun 2017 14:49, "jim deleskie"  wrote:

I see 5+ prepends as maybe not reason to have your "BGP driving license
revoked" but if I can continue with the concept that you have your BGP
learners permit.


That (6) seems pretty low to me. Apart from a potential bug the other
reason we thought of to block routes with a massive AS_PATH is that it
could be a sign that the operator of a network doesn't know what their
doing or doesn't have good processes in place (YMMV). If you have a path
twice in BGP, once with a "giant" path length and once with a "normal"
length the provider offering the "longer" path may have any manner of
problems internally if they can't even manage their BGP routing policies
appropriately.

I have seen genuine reasons for up to about 6 pre-prends and beyond so
you're probably dropping a decent amount of routes. At the time I set our
filter I think we were dropping one single route. No one has complained so
its still in place.

Giant AS_PATHs can be debated in a similar fashion to AS numbers
used/restricted by RFCs. We have AS number filters in place to block
prefixes with a private ASN in the path, any transit provider should block
such routes, again if they aren't it's a sign to me they're not doing a
really great job. But it's very hard to know if you can drop those routes
without affecting your customer base or that a suitable alternative exists.
Great care must be taken when doing this.

Otherwise the following issue arises:

On 21 Jun 2017 19:13, "Saku Ytti"  wrote:

Hey,

Uou're saying, you drop long AS_PATH, to improve customer observed
latency? Implication being, because you dropped the long AS_PATH
prefixes, you're now selecting shorter AS_PATH prefixes to the FIB?

Absent of this policy, in which scenario would you have inserted the
filtered longer AS_PATH prefix to the FIB? I assume only scenario
where this happens is where there is larger aggregate route, which is
lower latency than the more specific route with longer as_path.


So we drop "giant" AS_PATH length routes and routes with certain ASNs in
the path, but we are fairly certain we don't need them / our customers
don't need them etc. Not because we believe we are getting better (lower
latency routes) routes from somewhere else as Saku said above, we can't
feasibly "test" and compare the performance of every route we receive or
need/want, but to protect our infrastructure.

On 22 Jun 2017 16:54, "Jakob Heitz (jheitz)"  wrote:

23456 is AS_TRANS. Either your router does not support 4 byte AS or there
is a bug at AS 12956 or AS 12956 is intentionally prepending 23456.


This ties in with my point about specific ASN filtering. Its not a problem
seeing 23456 in your table but again perhaps an indicator of a problem or
someone using legacy kit. No problem with 23456 routes like AS_PATH length
of up to say 50 but beyond that, I can't thing of a genuine reasons and
could be a sign that along the path there may be stability issues for
example. Again, too difficult to measure.

Depending on your customer base and requirements it can be safe to drop
giant paths but care is needed, and if you do it, I think a number like 6
is way too low.

Cheers,
James.