IPv6 faster/better proof? was Re: Need /24 (arin) asap
--- cb.list6@gmail.com wrote: From: Ca By <cb.list6@gmail.com>
Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6
And Akaimai reports 80% of mobiles
And they both report ipv6 is faster / better. ---------------------------------------- Hmm... Faster and better? The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better. Akamai URL: "For dual-stacked hostnames we typically see higher average estimated throughput over IPv6 than over IPv4. Some of this may be due to IPv6-connected users being correlated with better connectivity, but over half of dual-stacked hostnames (weighted by daily bytes delivered) have IPv6 estimated throughput at least 50% faster than IPv4, and 90% of these hostnames have the IPv6 estimated throughput at least 10% faster than IPv4." FB URL: "People using Facebook services typically see better performance over IPv6..." and it points to https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-bo... which says: "We’ve long been anticipating the exhaustion of IPv in favor of the speed and performance benefits of IPv6." "We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6." I'd sure like to see how they came up with these numbers in a technically oriented paper. There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols. scott
On Mon, Jun 11, 2018 at 4:16 PM, Scott Weeks <surfer@mauigateway.com> wrote:
Hmm... Faster and better?
The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better.
Is it possible that simply having a much smaller routing table overall in terms of sheer number of prefixes in the DFZ has a positive performance impact on passing packets, which coupled with the fact that implementations may be routed better/more efficiently due to a lack of "legacy cruft" creates a better experience for many packets? Just a theory/hypothesis with no data to back it up.
I suspect that this may not be an apples to apples comparison. Perhaps lack of IPv6 is more prevalent in rural areas with poorer connectivity to the rest of the Internet? Perhaps both these CDNs serve content for different types of devices over the different AFIs (maybe old mediaboxes with a slow cpu prefer IPv4?). Perhaps networks that deploy IPv6 are more likely to allow and accommodate on-net caches? I theorize that the described speed difference between IPv4 and IPv6 is an artifact of how the data is analysed rather than an architectural speed difference between the protocols themselves. Kind regards, Job
On Mon, Jun 11, 2018 at 6:29 PM Job Snijders <job@instituut.net> wrote:
I suspect that this may not be an apples to apples comparison.
Perhaps lack of IPv6 is more prevalent in rural areas with poorer connectivity to the rest of the Internet? Perhaps both these CDNs serve content for different types of devices over the different AFIs (maybe old mediaboxes with a slow cpu prefer IPv4?). Perhaps networks that deploy IPv6 are more likely to allow and accommodate on-net caches?
I theorize that the described speed difference between IPv4 and IPv6 is an artifact of how the data is analysed rather than an architectural speed difference between the protocols themselves.
Besides the data bias that could indeed exist, I noticed many deployed traffic shapers not supporting IPV6, and imagine that some traffic engineering is currently being focused on IPv4 traffic. So even the protocol themselves having comparable performance, IPv6 bandwidth could be smoother than IPv4 bandwidth for some users. Perhaps instead of looking at global averages, we could look at speed comparison for dual-stacked users, like in how many of them see better or worse performance with v4/v6. Rubens
On Mon, Jun 11, 2018 at 2:29 PM Job Snijders <job@instituut.net> wrote:
I suspect that this may not be an apples to apples comparison.
Perhaps lack of IPv6 is more prevalent in rural areas with poorer connectivity to the rest of the Internet? Perhaps both these CDNs serve content for different types of devices over the different AFIs (maybe old mediaboxes with a slow cpu prefer IPv4?). Perhaps networks that deploy IPv6 are more likely to allow and accommodate on-net caches?
I theorize that the described speed difference between IPv4 and IPv6 is an artifact of how the data is analysed rather than an architectural speed difference between the protocols themselves.
Kind regards,
Job
A similar take, is that big eyeballs (tmobile, comcast, sprint, att, verizon wireless) and big content (goog, fb, akamai, netflix) are ipv6. Whats left on ipv4 is the long tail of people asking for help on how to buy a /24
On Mon, Jun 11, 2018 at 10:03 PM, Ca By <cb.list6@gmail.com> wrote:
A similar take, is that big eyeballs (tmobile, comcast, sprint, att, verizon wireless) and big content (goog, fb, akamai, netflix) are ipv6. Whats left on ipv4 is the long tail of people asking for help on how to buy a /24
Joking aside, I suspect that what's left is on the long tail is actually long haul traffic. I'm not aware of any transit provider reporting anything close to the numbers that the CDNs observe in terms of IPv4 / IPv6 percentage split. I posit that the more miles a packet has to travel, the more likely it is to be an IPv4 packet. Kind regards, Job
On Mon, Jun 11, 2018 at 3:08 PM Job Snijders <job@instituut.net> wrote:
On Mon, Jun 11, 2018 at 10:03 PM, Ca By <cb.list6@gmail.com> wrote:
A similar take, is that big eyeballs (tmobile, comcast, sprint, att, verizon wireless) and big content (goog, fb, akamai, netflix) are ipv6. Whats left on ipv4 is the long tail of people asking for help on how to buy a /24
Joking aside, I suspect that what's left is on the long tail is actually long haul traffic. I'm not aware of any transit provider reporting anything close to the numbers that the CDNs observe in terms of IPv4 / IPv6 percentage split.
I posit that the more miles a packet has to travel, the more likely it is to be an IPv4 packet.
Related. The more miles the traffic travels the more likely it is the long tail ipv4 15% of internet that is not the wales : google, fb, netflix, apple, akamai ... and i will even throw in cloudflare. I hear transit is dead https://blog.apnic.net/2016/10/28/the-death-of-transit/
Kind regards,
Job
On Mon, Jun 11, 2018 at 05:01:24PM -0700, Ca By wrote:
I posit that the more miles a packet has to travel, the more likely it is to be an IPv4 packet.
Related. The more miles the traffic travels the more likely it is the long tail ipv4 15% of internet that is not the wales : google, fb, netflix, apple, akamai ... and i will even throw in cloudflare.
I hear transit is dead
Well, be that as it may, I'm still going to go to work tomorrow ;-) - Job
On Jun 11, 2018, at 8:07 PM, Job Snijders <job@instituut.net> wrote:
On Mon, Jun 11, 2018 at 05:01:24PM -0700, Ca By wrote:
I posit that the more miles a packet has to travel, the more likely it is to be an IPv4 packet.
Related. The more miles the traffic travels the more likely it is the long tail ipv4 15% of internet that is not the wales : google, fb, netflix, apple, akamai ... and i will even throw in cloudflare.
I hear transit is dead
Well, be that as it may, I'm still going to go to work tomorrow ;-)
I see in the SMB space, including the small time FTTH and WISP communities they are mostly focused on IPv4 with little IPv6 going on. While they could access most content on IPv6 their common platforms still are not IPv6 friendly. UBNT is rolling out IPv6 finally to some of their UniFi lines as well as their airOS 8.x by making it default enabled. There is still some way to go but folks are making progress. MikroTik is getting there but most people are just not enabling it either. The WISP folks gripe about geolocation issues for the IPv4 blocks they are leasing as well, and some end-user content still isn’t IPv6 ready (such as Hulu). What I can see is that the folks that made the jump are less likely to be required to hold NAT state so have fewer problems. It’s not quite as simple as 96-more-bits because you learn there is no ARP (it’s NDP) and you can DHCPv6 + SLAAC or a combination thereof, but they just don’t have the operational experience. There’s also the perfectly valid comments from others that they can’t get IPv6 on their FIOS, Business class DOCSIS services, etc.. It’s also often easier to get a static IPv4 and dynamic IPv6 but getting static IPv6 is harder. Thankfully progress is being made here, but often much slower than the early adopters here would want. Then again, I hear everything is in the cloud anyways so as long as I can reach the NetBookAzureTube perhaps all is well? - Jared
On 6/19/18 8:48 PM, Jared Mauch wrote:
MikroTik is getting there but most people are just not enabling it either.
RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops dependent on Mikrotik want to move forward with deploying it.
On Tue, Jun 19, 2018 at 7:56 PM Seth Mattinen <sethm@rollernet.us> wrote:
On 6/19/18 8:48 PM, Jared Mauch wrote:
MikroTik is getting there but most people are just not enabling it either.
RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops dependent on Mikrotik want to move forward with deploying it.
Quick, somebody port FRR to Tile… <ducks> -- Jeremy Austin jhaustin@gmail.com (907) 895-2311 office (907) 803-5422 cell Heritage NetWorks - Whitestone Power & Communications - Vertical Broadband, LLC
On Jun 19, 2018, at 11:55 PM, Seth Mattinen <sethm@rollernet.us> wrote:
On 6/19/18 8:48 PM, Jared Mauch wrote:
MikroTik is getting there but most people are just not enabling it either.
RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops dependent on Mikrotik want to move forward with deploying it.
I know. They’re very popular in the WISP and FTTH communities that are doing sub-10G as their aggregate bits. I understand the price appeal but not a fan personally. - Jared
On 20/Jun/18 06:06, Jared Mauch wrote:
I know. They’re very popular in the WISP and FTTH communities that are doing sub-10G as their aggregate bits. I understand the price appeal but not a fan personally.
Not a fan either for the backbone, even though a lot of ISP's in South Africa use them for this... admittedly, small networks that simply don't have the cash to dish out to the big vendors. I know we've had some issues setting up BGP sessions with MikroTik-based customers/peers, mainly around how RouterOS interprets various BGP-related RFC's. But for the home, I can't fault them. They do fix plenty of bugs (almost as much as they push out new features). I have seen some IPv6 bug fixes in recent updates they've published, but nothing that really makes a difference to my home world, as far as I can remember. Mark.
Not much limiting them to the sub-10G world, though. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" <jared@puck.nether.net> To: "Seth Mattinen" <sethm@rollernet.us> Cc: nanog@nanog.org Sent: Tuesday, June 19, 2018 11:06:24 PM Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap
On Jun 19, 2018, at 11:55 PM, Seth Mattinen <sethm@rollernet.us> wrote:
On 6/19/18 8:48 PM, Jared Mauch wrote:
MikroTik is getting there but most people are just not enabling it either.
RouterOS still has "will not fix" IPv6 bugs, so that doesn't help shops dependent on Mikrotik want to move forward with deploying it.
I know. They’re very popular in the WISP and FTTH communities that are doing sub-10G as their aggregate bits. I understand the price appeal but not a fan personally. - Jared
On 20/Jun/18 05:48, Jared Mauch wrote:
MikroTik is getting there but most people are just not enabling it either.
I have a MikroTik hAP Lite router for my FTTH service at my house. It has excellent support for IPv6, including a ton of translation mechanisms. My problem is my home provider doesn't do IPv6, so I run a 6-in-4 tunnel back to my own backbone for the service (no latency impact as my home provider is my IP Transit customer :-) ). This is a little unstable because my home provider doesn't know how to give me a stable IPv4 address for my FTTH service. But I do have to say that I am massively impressed by what that little MikroTik box can do. IPv6 on my home LAN works as expected, as it does across the 6-in-4 tunnel. Mark.
I've many customers using MikroTik. The problem with its IPv6 support is that is only supporting 6in4, which by the way, they call it 6to4, so it is very weird and confusing customers ... So for native IPv6 or a 6in4 tunnel, is fine, but any other transition mechanism is NOT supported, so we end up reflashing then with OpenWRT. Regards, Jordi -----Mensaje original----- De: NANOG <nanog-bounces@nanog.org> en nombre de Mark Tinka <mark.tinka@seacom.mu> Fecha: viernes, 22 de junio de 2018, 9:07 Para: Jared Mauch <jared@puck.nether.net>, Job Snijders <job@instituut.net> CC: North American Network Operators' Group <nanog@nanog.org> Asunto: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 20/Jun/18 05:48, Jared Mauch wrote: > MikroTik is getting there but most people are just not enabling it either. I have a MikroTik hAP Lite router for my FTTH service at my house. It has excellent support for IPv6, including a ton of translation mechanisms. My problem is my home provider doesn't do IPv6, so I run a 6-in-4 tunnel back to my own backbone for the service (no latency impact as my home provider is my IP Transit customer :-) ). This is a little unstable because my home provider doesn't know how to give me a stable IPv4 address for my FTTH service. But I do have to say that I am massively impressed by what that little MikroTik box can do. IPv6 on my home LAN works as expected, as it does across the 6-in-4 tunnel. Mark. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 22/Jun/18 10:00, JORDI PALET MARTINEZ via NANOG wrote:
The problem with its IPv6 support is that is only supporting 6in4, which by the way, they call it 6to4, so it is very weird and confusing customers ...
That "6-to-4 actually means 6-in-4" was quite confusing to me as well. I just enabled it to prove that they had a language moment there. Good thing it didn't backfire on me :-).
So for native IPv6 or a 6in4 tunnel, is fine, but any other transition mechanism is NOT supported, so we end up reflashing then with OpenWRT.
Not sure I'd blame them either - they develop a lot of features for pretty much next-to-nothing; and are being enabled by customers that are willing to take the risk for relief on budget. They could be more inclined to fix bugs and develop corner-case features sooner if they were in the premium market. But, as my (well-known on this list) American friend would say, "I conjecturbate" :-). Mark.
The problem with its IPv6 support is that is only supporting 6in4, which by the way, they call it 6to4, so it is very weird and confusing customers ... That "6-to-4 actually means 6-in-4" was quite confusing to me as well. I just enabled it to prove that they had a language moment there. Good thing it didn't backfire on me :-). Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but it is very confusing and against standards nomenclature … This don’t say anything good from a vendor, in my opinion! So for native IPv6 or a 6in4 tunnel, is fine, but any other transition mechanism is NOT supported, so we end up reflashing then with OpenWRT. Not sure I'd blame them either - they develop a lot of features for pretty much next-to-nothing; and are being enabled by customers that are willing to take the risk for relief on budget. I’ve got very good customers from Mikrotik asking them in private and in public and they even didn’t reply. No other transition mechanism is available, no roadmap. So, you can’t use them for example for an IPv6-only access network which clearly is what is needed now. They could be more inclined to fix bugs and develop corner-case features sooner if they were in the premium market. But, as my (well-known on this list) American friend would say, "I conjecturbate" :-). They basically run a Linux … and you have OpenWRT sources with all what they need to implement 4in6 transition mechanisms, so no excuses! I must say also that no excuses for other CPE vendors, of course, but others at least have DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will change soon. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 22/Jun/18 12:47, JORDI PALET MARTINEZ wrote:
Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but it is very confusing and against standards nomenclature … This don’t say anything good from a vendor, in my opinion!
Even those networks I know running MikroTik for revenue generation don't run around saying they think they are working with the best vendor :-). But the truth is in the numbers - I'm to find another vendor in my parts that sells more gear without presence in any country on the continent.
They basically run a Linux … and you have OpenWRT sources with all what they need to implement 4in6 transition mechanisms, so no excuses! I must say also that no excuses for other CPE vendors, of course, but others at least have DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will change soon.
On the plus side, MikroTik regularly push out updates for their devices, unlike traditional home CPE whose updates tend to disappear one year after you buy and install them, leaving the only option to update software being a hardware swap-out. Can MikroTik do more, certainly. But this is clearly a case of "you get what you pay for". On the other hand, Cisco have (yet again) delayed ORR until 2019/2020, if at all. Juniper have screwed up their EX switch CLI with this ELS monstrosity, a problem they hope to correct in 2019/2020, if at all. And I'm paying through eyes for those puppies... Mark.
I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you. And of course, you don’t depend on a specific hardware vendor. You can have a single model or several ones depending on customer’s needs, but all share the same firmware. You can buy very good quality products from China with 1-5 FastEthernet or Gigabit ports, 1 or dual radio WiFi, 1 or several USB (2.0 or 3.0), with or without Bluetooth, SD card support, even SATA support, and even LTE support. You have so many vendors that you can even decide what CPU you prefer to have and even what Wireless chips … A basic one will be around 15 USD, the most powerful one will be around 30 USD (without the LTE interface, but space for it). Regards, Jordi De: Mark Tinka <mark.tinka@seacom.mu> Fecha: viernes, 22 de junio de 2018, 13:23 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: "nanog@nanog.org" <nanog@nanog.org> Asunto: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 22/Jun/18 12:47, JORDI PALET MARTINEZ wrote: Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but it is very confusing and against standards nomenclature … This don’t say anything good from a vendor, in my opinion! Even those networks I know running MikroTik for revenue generation don't run around saying they think they are working with the best vendor :-). But the truth is in the numbers - I'm to find another vendor in my parts that sells more gear without presence in any country on the continent. They basically run a Linux … and you have OpenWRT sources with all what they need to implement 4in6 transition mechanisms, so no excuses! I must say also that no excuses for other CPE vendors, of course, but others at least have DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will change soon. On the plus side, MikroTik regularly push out updates for their devices, unlike traditional home CPE whose updates tend to disappear one year after you buy and install them, leaving the only option to update software being a hardware swap-out. Can MikroTik do more, certainly. But this is clearly a case of "you get what you pay for". On the other hand, Cisco have (yet again) delayed ORR until 2019/2020, if at all. Juniper have screwed up their EX switch CLI with this ELS monstrosity, a problem they hope to correct in 2019/2020, if at all. And I'm paying through eyes for those puppies... Mark. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
On 22/Jun/18 15:05, JORDI PALET MARTINEZ via NANOG wrote:
I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you.
No one disputes that, but there is a reason why operators are paying for MikroTik instead of taking a white box and flashing it with free code from any number of sources. They could either spend time developing free code on white boxes to a level where it does everything they want, or they could decide for what MikroTik offers for an integrated solution (hardware + software), the time and effort are outweighed by the cost, as a function of traditional alternatives such as Cisco, Juniper, Nokia, Brocade, e.t.c. Joe Average has neither the experience nor the inclination to flash whatever box he has with OpenWRT. You and I do (well, I've grown lazy, so...). Copy & paste for FTTH service providers dealing with thousands or millions of customers who want to pay nothing for 1Gbps to their house, and you quickly see why this is not an easy problem to solve. Pity that vCPE's don't seem to be picking up as they were once touted to... that would have been an easy truck-roll for IPv6 to everyone that guaranteed it would work, always! Mark.
On Jun 22, 2018, at 9:31 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 22/Jun/18 15:05, JORDI PALET MARTINEZ via NANOG wrote:
I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you.
No one disputes that, but there is a reason why operators are paying for MikroTik instead of taking a white box and flashing it with free code from any number of sources.
They could either spend time developing free code on white boxes to a level where it does everything they want, or they could decide for what MikroTik offers for an integrated solution (hardware + software), the time and effort are outweighed by the cost, as a function of traditional alternatives such as Cisco, Juniper, Nokia, Brocade, e.t.c.
Joe Average has neither the experience nor the inclination to flash whatever box he has with OpenWRT. You and I do (well, I've grown lazy, so...). Copy & paste for FTTH service providers dealing with thousands or millions of customers who want to pay nothing for 1Gbps to their house, and you quickly see why this is not an easy problem to solve.
I’ve found most folks doing Tik need the GUI, etc to interact with the devices. I can’t say I blame them in some ways either. Have you tried to upgrade an IOS-XR device before? One-click updates in Tik are much easier. Even UBNT it’s fairly straightforward. Personally I use Tik for layer-2 stuff, be it media converters or switches where there’s not some other alternative that makes more sense. I’m comfortable with a CLI, but most people I’ve tried to say “hey, use this it’s better” say “I can’t http/https to it, the learning curve is too steep”. - Jared
in small corners, e.g. home, i use ubiquiti erx. i use the cli for config, and the gooey for watching traffic levels in pretty colors. they play well with both concast and at&t u-verse ipv4 and ipv6. in san jose $dayjob, i am stuck with a cisco asa for cpe, a 1990s retro antique providing job security for a thousand engineers who maximize complexity. randy
On 23/Jun/18 20:14, Randy Bush wrote:
in small corners, e.g. home, i use ubiquiti erx. i use the cli for config, and the gooey for watching traffic levels in pretty colors. they play well with both concast and at&t u-verse ipv4 and ipv6.
That was a good tip, as I hadn't seen these before this thread. One thing I like about the MikroTik is that it goes forever without needing a reboot. My previous Claix GPON ONU + IP Router combo box needed a reboot a couple of times a year as it was running out of memory to hold NAT44 state. Same thing as my previous Netgear and Linksys routers. The MikroTik; well, had for almost 2 years and only reboot it to do software updates. Mark.
That was a good tip, as I hadn't seen these before this thread.
they also make a good small-isp or large office router for USD 300 https://www.ubnt.com/edgemax/edgerouter-pro/
One thing I like about the MikroTik is that it goes forever without needing a reboot.
while i have not run a ubiquiti forever, i have run them for a very long time.
My previous Claix GPON ONU + IP Router combo box needed a reboot a couple of times a year as it was running out of memory to hold NAT44 state.
quaint i think microtik and ubiquiti are the two serious home geek cpe players of note. i was mostly happy with a netgear into which i blew openwrt, but the netgear was mediocre hardware. randy
I’ll cop to ubiquiti at home and at work too (mainly for Wi-Fi and some ptp backhaul in which they are very strong). Any kind of HA in their routers keeps them out my enterprise clients of mine, let alone my network core. -Ben On Jun 25, 2018, at 6:50 AM, Randy Bush <randy@psg.com> wrote:
That was a good tip, as I hadn't seen these before this thread.
they also make a good small-isp or large office router for USD 300 https://www.ubnt.com/edgemax/edgerouter-pro/
One thing I like about the MikroTik is that it goes forever without needing a reboot.
while i have not run a ubiquiti forever, i have run them for a very long time.
My previous Claix GPON ONU + IP Router combo box needed a reboot a couple of times a year as it was running out of memory to hold NAT44 state.
quaint
i think microtik and ubiquiti are the two serious home geek cpe players of note. i was mostly happy with a netgear into which i blew openwrt, but the netgear was mediocre hardware.
randy
On 25/Jun/18 15:57, Ben Cannon wrote:
I’ll cop to ubiquiti at home and at work too (mainly for Wi-Fi and some ptp backhaul in which they are very strong). Any kind of HA in their routers keeps them out my enterprise clients of mine, let alone my network core.
With pressure on pricing in some of our markets in Africa, we are seeing Enterprise customers asking for el-cheapo router options, and MikroTik has been right up there with plenty for sub-1Gbps deliveries. I'm thinking the Ubiquiti ERX could be a viable option, as it pays to have more than one from the pot. Mark.
A couple of the big draws to Mikrotik (aside from the performance and features you get for the price) are Winbox, Torch, and real-time stats. Great features that don't really have an equal elsewhere. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Jared Mauch" <jared@puck.nether.net> To: "Mark Tinka" <mark.tinka@seacom.mu> Cc: nanog@nanog.org Sent: Saturday, June 23, 2018 6:17:15 AM Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap
On Jun 22, 2018, at 9:31 AM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On 22/Jun/18 15:05, JORDI PALET MARTINEZ via NANOG wrote:
I’m not really sure “you get what you pay for” … compare with OpenWRT … you have frequent updates, even in days when some important security flaw is discovered, as it happened a few months ago with WiFi. You can even develop yourself what you want or pay folks to do it for you.
No one disputes that, but there is a reason why operators are paying for MikroTik instead of taking a white box and flashing it with free code from any number of sources.
They could either spend time developing free code on white boxes to a level where it does everything they want, or they could decide for what MikroTik offers for an integrated solution (hardware + software), the time and effort are outweighed by the cost, as a function of traditional alternatives such as Cisco, Juniper, Nokia, Brocade, e.t.c.
Joe Average has neither the experience nor the inclination to flash whatever box he has with OpenWRT. You and I do (well, I've grown lazy, so...). Copy & paste for FTTH service providers dealing with thousands or millions of customers who want to pay nothing for 1Gbps to their house, and you quickly see why this is not an easy problem to solve.
I’ve found most folks doing Tik need the GUI, etc to interact with the devices. I can’t say I blame them in some ways either. Have you tried to upgrade an IOS-XR device before? One-click updates in Tik are much easier. Even UBNT it’s fairly straightforward. Personally I use Tik for layer-2 stuff, be it media converters or switches where there’s not some other alternative that makes more sense. I’m comfortable with a CLI, but most people I’ve tried to say “hey, use this it’s better” say “I can’t http/https to it, the learning curve is too steep”. - Jared
On 23/Jun/18 13:17, Jared Mauch wrote:
I’ve found most folks doing Tik need the GUI, etc to interact with the devices. I can’t say I blame them in some ways either. Have you tried to upgrade an IOS-XR device before?
If I'm honest, one of the reasons I continue to go with the MX480 in the edge, as opposed to an ASR9000.
One-click updates in Tik are much easier. Even UBNT it’s fairly straightforward. Personally I use Tik for layer-2 stuff, be it media converters or switches where there’s not some other alternative that makes more sense. I’m comfortable with a CLI, but most people I’ve tried to say “hey, use this it’s better” say “I can’t http/https to it, the learning curve is too steep”.
I use the GUI myself. I've fiddled around with the RouterOS CLI, and while it's not difficult to learn, I'm old and lazy now. The GUI is very well laid out, does everything it says it's supposed to do, which is fine by me. Mark.
Your last paragraph hits it on the head. I hear people bash Mikrotik, but then I've heard many times people with $$$$ vendor's gear complaining just as much (just about different things) and they're paying significantly more for that privilege. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "Mark Tinka" <mark.tinka@seacom.mu> To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> Cc: nanog@nanog.org Sent: Friday, June 22, 2018 6:23:21 AM Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 22/Jun/18 12:47, JORDI PALET MARTINEZ wrote:
Yeah I can confirm, as I tested it several times, 6to4 for them is proto41, but it is very confusing and against standards nomenclature … This don’t say anything good from a vendor, in my opinion!
Even those networks I know running MikroTik for revenue generation don't run around saying they think they are working with the best vendor :-). But the truth is in the numbers - I'm to find another vendor in my parts that sells more gear without presence in any country on the continent.
They basically run a Linux … and you have OpenWRT sources with all what they need to implement 4in6 transition mechanisms, so no excuses! I must say also that no excuses for other CPE vendors, of course, but others at least have DS-Lite or even lw4o6. Very few offer 464XLAT (CLAT part is what the CPE needs) or MAP-T/E. Hopefully this will change soon.
On the plus side, MikroTik regularly push out updates for their devices, unlike traditional home CPE whose updates tend to disappear one year after you buy and install them, leaving the only option to update software being a hardware swap-out. Can MikroTik do more, certainly. But this is clearly a case of "you get what you pay for". On the other hand, Cisco have (yet again) delayed ORR until 2019/2020, if at all. Juniper have screwed up their EX switch CLI with this ELS monstrosity, a problem they hope to correct in 2019/2020, if at all. And I'm paying through eyes for those puppies... Mark.
On Mon, Jun 11, 2018 at 5:03 PM, Ca By <cb.list6@gmail.com> wrote:
A similar take, is that big eyeballs (tmobile, comcast, sprint, att, verizon wireless)
There're a lot of big eyeball networks missing from that list. Spectrum biz class, no IPv6, for one. And some big "content"-ish ones, too. Google's cloud service, for example? No IPv6 for VMs you lease from them. And some of the biggest "web hosting providers" in the world still don't have IPv6 deployed, and they host millions if not billions of sites which, individually, have very little traffic, but in aggregate amount to a fair bit.
On 06/11/2018 05:16 PM, Scott Weeks wrote:
--- cb.list6@gmail.com wrote: From: Ca By <cb.list6@gmail.com>
Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6
And Akaimai reports 80% of mobiles And they both report ipv6 is faster / better.
Let me grab a few more for you: https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why... https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time which cites an academic paper http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai and Jürgen Schönwälder https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/ https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-tha... https://www.nanog.org/meetings/abstract?id=2281
I'd sure like to see how they came up with these numbers in a technically oriented paper. Most of the above links explain how they got the numbers. Facebook, in particular, did A/B testing using Mobile Proxygen, which is to say that they configured their mobile app to report performance over both IPv4 and IPv6 from the same handset at the same time. Others, including APNIC's https://stats.labs.apnic.net/v6perf have a browser fetch two objects with unique URLs, one from an IPv4-only server and one from an IPv6-only server, and compare them.
There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols.
From time to time somebody says, "Okay, maybe it works in practice, but does it work in *theory*?" Busy engineers hardly ever investigate things going inexplicably right. My hypothesis is that the observed difference in performance relates to how mobile networks deploy their transition mechanisms. Those with a dual-stack APN take a native path for IPv6, while using a CGN path for IPv4, which, combined with the Happy Eyeballs head start, might add 501microseconds, which is a ms, which is 15% of 7ms. Those with an IPv6-only APN use a native path for IPv6, while using either a NAT64 for IPv4 (identical performance to CGN) or 464xlat, which requires translation both in the handset and the NAT64; handsets may not be optimized for header translation. However, I have a dozen other hypotheses, and the few experiments I've been able to run have not confirmed any hypothesis. For instance, when one protocol is faster than another on a landline network, hop count is not a correlation (therefore, shorter paths, traffic engineering, etc., are not involved). Lee
Hmm... Faster and better?
The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better.
Akamai URL:
"For dual-stacked hostnames we typically see higher average estimated throughput over IPv6 than over IPv4. Some of this may be due to IPv6-connected users being correlated with better connectivity, but over half of dual-stacked hostnames (weighted by daily bytes delivered) have IPv6 estimated throughput at least 50% faster than IPv4, and 90% of these hostnames have the IPv6 estimated throughput at least 10% faster than IPv4."
FB URL:
"People using Facebook services typically see better performance over IPv6..."
and it points to https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-bo... which says:
"We’ve long been anticipating the exhaustion of IPv in favor of the speed and performance benefits of IPv6."
"We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6."
I'd sure like to see how they came up with these numbers in a technically oriented paper. There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols.
scott
Although the FB link is vague but argument itself is true. We just became more intelligent in deploying IPV6. The same measurement if was done in less than a decade for example would show that ipv4 is faster. The dual stack implementation and the slowness introduced by Teredo Tunneling were the main reasons and now we are getting smarter having it deprecating https://labs.ripe.net/Members/gih/examining-ipv6-performance https://tools.ietf.org/html/rfc6555 https://tools.ietf.org/html/rfc7526 Things change, Ipv6 response is showing better has IPV4 is having more TCP re-transmission which the culprit is still not known ( need more analysis) but fingers are pointing to the exhaustion of the ipv4 address so basically CGN , load-balancers and address sharing. Although we can not eliminate peering links and Firewalls. Yet if we have exactly the same topology and traffic crossing the links et Firewalls locations/policies. Analysis didnot confirm why it would have rather more harm on ipv4 than 6 Brgds, LG ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Lee Howard <lee.howard@retevia.net> Sent: Wednesday, June 13, 2018 7:46 AM To: nanog@nanog.org Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On 06/11/2018 05:16 PM, Scott Weeks wrote:
--- cb.list6@gmail.com wrote: From: Ca By <cb.list6@gmail.com>
Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6
And Akaimai reports 80% of mobiles And they both report ipv6 is faster / better.
Let me grab a few more for you: https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why... Preparing for IPv6-only mobile networks: Why and How - The ...<https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html> blogs.akamai.com Apple's upcoming App Store submission requirement around supporting IPv6-only environments (announced last year at WWDC and being enforced starting June 1) has been getting plenty of recent coverage. iOS application developers already need to make sure their applications work in... https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time which cites an academic paper http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai and Jürgen Schönwälder https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/ https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-tha... https://www.nanog.org/meetings/abstract?id=2281
I'd sure like to see how they came up with these numbers in a technically oriented paper. Most of the above links explain how they got the numbers. Facebook, in particular, did A/B testing using Mobile Proxygen, which is to say that they configured their mobile app to report performance over both IPv4 and IPv6 from the same handset at the same time. Others, including APNIC's https://stats.labs.apnic.net/v6perf have a browser fetch two objects with unique URLs, one from an IPv4-only server and one from an IPv6-only server, and compare them.
There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols.
From time to time somebody says, "Okay, maybe it works in practice, but does it work in *theory*?" Busy engineers hardly ever investigate things going inexplicably right. My hypothesis is that the observed difference in performance relates to how mobile networks deploy their transition mechanisms. Those with a dual-stack APN take a native path for IPv6, while using a CGN path for IPv4, which, combined with the Happy Eyeballs head start, might add 501microseconds, which is a ms, which is 15% of 7ms. Those with an IPv6-only APN use a native path for IPv6, while using either a NAT64 for IPv4 (identical performance to CGN) or 464xlat, which requires translation both in the handset and the NAT64; handsets may not be optimized for header translation. However, I have a dozen other hypotheses, and the few experiments I've been able to run have not confirmed any hypothesis. For instance, when one protocol is faster than another on a landline network, hop count is not a correlation (therefore, shorter paths, traffic engineering, etc., are not involved). Lee
Hmm... Faster and better?
The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better.
Akamai URL:
"For dual-stacked hostnames we typically see higher average estimated throughput over IPv6 than over IPv4. Some of this may be due to IPv6-connected users being correlated with better connectivity, but over half of dual-stacked hostnames (weighted by daily bytes delivered) have IPv6 estimated throughput at least 50% faster than IPv4, and 90% of these hostnames have the IPv6 estimated throughput at least 10% faster than IPv4."
FB URL:
"People using Facebook services typically see better performance over IPv6..."
and it points to https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-bo... which says:
"We’ve long been anticipating the exhaustion of IPv in favor of the speed and performance benefits of IPv6."
"We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6."
I'd sure like to see how they came up with these numbers in a technically oriented paper. There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols.
scott
From an Apple device point of view, ipv6 should be faster than ipv4 where both are available. Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution. https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/ So if you test facebook from a Mac/iPhone/iPad, it will definitely loads faster over ipv6 On 06/19/2018 08:32 PM, lobna gouda wrote:
Although the FB link is vague but argument itself is true. We just became more intelligent in deploying IPV6. The same measurement if was done in less than a decade for example would show that ipv4 is faster. The dual stack implementation and the slowness introduced by Teredo Tunneling were the main reasons and now we are getting smarter having it deprecating
https://labs.ripe.net/Members/gih/examining-ipv6-performance
https://tools.ietf.org/html/rfc6555
https://tools.ietf.org/html/rfc7526 Things change, Ipv6 response is showing better has IPV4 is having more TCP re-transmission which the culprit is still not known ( need more analysis) but fingers are pointing to the exhaustion of the ipv4 address so basically CGN , load-balancers and address sharing. Although we can not eliminate peering links and Firewalls. Yet if we have exactly the same topology and traffic crossing the links et Firewalls locations/policies. Analysis didnot confirm why it would have rather more harm on ipv4 than 6
Brgds,
LG
________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Lee Howard <lee.howard@retevia.net> Sent: Wednesday, June 13, 2018 7:46 AM To: nanog@nanog.org Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap
On 06/11/2018 05:16 PM, Scott Weeks wrote:
--- cb.list6@gmail.com wrote: From: Ca By <cb.list6@gmail.com>
Meanwhile, FB reports that 75% of mobiles in the USA reach them via ipv6
And Akaimai reports 80% of mobiles And they both report ipv6 is faster / better.
Let me grab a few more for you:
https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why... Preparing for IPv6-only mobile networks: Why and How - The ...<https://blogs.akamai.com/2016/06/preparing-for-ipv6-only-mobile-networks-why-and-how.html> blogs.akamai.com Apple's upcoming App Store submission requirement around supporting IPv6-only environments (announced last year at WWDC and being enforced starting June 1) has been getting plenty of recent coverage. iOS application developers already need to make sure their applications work in...
https://blogs.akamai.com/2016/10/ipv6-at-akamai-edge-2016.html
https://www.theregister.co.uk/2016/07/28/ipv6_now_faster_a_fifth_of_the_time which cites an academic paper http://dl.acm.org/citation.cfm?doid=2959424.2959429 by Vaibhav Bajpai and Jürgen Schönwälder
https://www.linkedin.com/pulse/ipv6-measurements-zaid-ali-kahn/
https://community.infoblox.com/t5/IPv6-CoE-Blog/Can-IPv6-Rally-Be-Faster-tha...
https://www.nanog.org/meetings/abstract?id=2281
I'd sure like to see how they came up with these numbers in a technically oriented paper. Most of the above links explain how they got the numbers. Facebook, in particular, did A/B testing using Mobile Proxygen, which is to say that they configured their mobile app to report performance over both IPv4 and IPv6 from the same handset at the same time. Others, including APNIC's https://stats.labs.apnic.net/v6perf have a browser fetch two objects with unique URLs, one from an IPv4-only server and one from an IPv6-only server, and compare them.
There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols. From time to time somebody says, "Okay, maybe it works in practice, but does it work in *theory*?"
Busy engineers hardly ever investigate things going inexplicably right.
My hypothesis is that the observed difference in performance relates to how mobile networks deploy their transition mechanisms. Those with a dual-stack APN take a native path for IPv6, while using a CGN path for IPv4, which, combined with the Happy Eyeballs head start, might add 501microseconds, which is a ms, which is 15% of 7ms. Those with an IPv6-only APN use a native path for IPv6, while using either a NAT64 for IPv4 (identical performance to CGN) or 464xlat, which requires translation both in the handset and the NAT64; handsets may not be optimized for header translation.
However, I have a dozen other hypotheses, and the few experiments I've been able to run have not confirmed any hypothesis. For instance, when one protocol is faster than another on a landline network, hop count is not a correlation (therefore, shorter paths, traffic engineering, etc., are not involved).
Lee
Hmm... Faster and better?
The links seem to be an IPv6 cheerleader write up. I looked at the URLs and the URLs one pointed to and pulled out everything related to IPv6 being faster/better.
Akamai URL:
"For dual-stacked hostnames we typically see higher average estimated throughput over IPv6 than over IPv4. Some of this may be due to IPv6-connected users being correlated with better connectivity, but over half of dual-stacked hostnames (weighted by daily bytes delivered) have IPv6 estimated throughput at least 50% faster than IPv4, and 90% of these hostnames have the IPv6 estimated throughput at least 10% faster than IPv4."
FB URL:
"People using Facebook services typically see better performance over IPv6..."
and it points to https://code.facebook.com/posts/1192894270727351/ipv6-it-s-time-to-get-on-bo... which says:
"We’ve long been anticipating the exhaustion of IPv in favor of the speed and performance benefits of IPv6."
"We’ve observed that accessing Facebook can be 10-15 percent faster over IPv6."
I'd sure like to see how they came up with these numbers in a technically oriented paper. There should be no difference, except for no CGN or Happy Eyeballs working better or something similar. Am I missing something? Same routers; same links; same RTTs; same interrupt times on servers; same etc, etc for both protocols.
scott
On Sat, 23 Jun 2018 12:27:35 -0400, "Jean | ddostest.me via NANOG" said:
Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution.
https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/
Umm.. It's 3 year old news that Apple implemented Happy Eyeballs. And if you read, it continues on saying that both Firefox and Chrome use a 300ms timer rather than 25ms. The solution is, of course, to not build websites that need to hit 20 or 30 IPv4-only tracking and affiliate and ad sites. :)
My guessing, it is rather a proof than a cause. Apple wanted to push their dev to see more ipv6 traffic with HE algorithm before working with IPv6 only -based on their assumption that the throughput may be better over IPv6 and with better V6 implementation eventually they are not going to be trading it with latency. https://www.internetsociety.org/blog/2016/05/starting-june-1-apple-requires-... By the way, the same argument is adopted to justify a good practice for SDN and IOT implementations. Basically the need for an v6-based networks -where there is no correlation other than the need for more addresses to achieve manageability and the ability to scale. Big ISPs are starting to realize this market and are performing the changes to get this business. https://searchsdn.techtarget.com/feature/IPv6-SDN-When-worlds-collide-in-a-g... Brgds, LG [https://cdn.ttgtmedia.com/ITKE/images/logos/TTlogo-379x201.png]<https://searchsdn.techtarget.com/feature/IPv6-SDN-When-worlds-collide-in-a-good-way> IPv6, SDN: When worlds collide ... in a good way<https://searchsdn.techtarget.com/feature/IPv6-SDN-When-worlds-collide-in-a-good-way> searchsdn.techtarget.com What do IPv6 and software-defined networking have in common? Not a lot, but then again, oh so much. Both IPv6 and SDN stand to radically change the way we build networks, and if implemented correctly, both play a role in making the cloud and IT as a Service more of a reality. In this two-part guide ... Starting June 1, Apple Requires All iOS Apps To Work in ...<https://www.internetsociety.org/blog/2016/05/starting-june-1-apple-requires-all-ios-apps-to-work-in-ipv6-only-networks/> www.internetsociety.org Back at their June 2015 WWDC event, Apple announced that all iOS 9 applications must support IPv6. This week Apple declared that as of June 1 all apps submitted to the AppStore MUST support IPv6-only networking. ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of valdis.kletnieks@vt.edu <valdis.kletnieks@vt.edu> Sent: Saturday, June 23, 2018 5:16 PM To: Jean | ddostest.me Cc: nanog@nanog.org Subject: Re: IPv6 faster/better proof? was Re: Need /24 (arin) asap On Sat, 23 Jun 2018 12:27:35 -0400, "Jean | ddostest.me via NANOG" said:
Because, Apple adds a 25 ms artifical penalty to ipv4 dns resolution.
https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/ [https://ma.ttias.be/wp-content/uploads/2015/07/official-apple-logo.png]<https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/>
Apple Favours IPv6, Gives IPv4 a 25ms Penalty - ma.ttias.be<https://ma.ttias.be/apple-favours-ipv6-gives-ipv4-a-25ms-penalty/> ma.ttias.be This is pretty exciting news for the adoption of IPv6. Last month, Apple announced that all iOS9 apps need to be "IPv6 compatible". Because IPv6 support is so critical to ensuring your applications work across the world for every customer, we are making it an AppStore submission requirement ... Umm.. It's 3 year old news that Apple implemented Happy Eyeballs. And if you read, it continues on saying that both Firefox and Chrome use a 300ms timer rather than 25ms. The solution is, of course, to not build websites that need to hit 20 or 30 IPv4-only tracking and affiliate and ad sites. :)
participants (17)
-
Ben Cannon -
Ca By -
Jared Mauch -
Jean | ddostest.me -
Jeremy Austin -
Job Snijders -
JORDI PALET MARTINEZ -
Lee Howard -
lobna gouda -
Mark Tinka -
Matt Harris -
Mike Hammett -
Randy Bush -
Rubens Kuhl -
Scott Weeks -
Seth Mattinen -
valdis.kletnieks＠vt.edu