WE Need IPV6 Support in MX

[cantechit]

Subject says it all...  We need proper IPV6 support in the MX Platform...    Even IPV6 tunnelling doesn't work at this point.

Anyone else have soem comments?

[BHC_RESORTS]

---

@cantechit wrote:

Subject says it all...  We need proper IPV6 support in the MX Platform...    Even IPV6 tunnelling doesn't work at this point.

Anyone else have soem comments?

---

Can't agree enough. Specifically, on the WAN portion.

[micahawitt]

I have spent about a total of 8 hours over the last few weeks searching upon scouring the interwebs and my portal for any sort of snippet on this.

Nothing, its the same sob story, im kind of amazed how they do not have this implemented.  I am actually starting to pull some of my clients from this and switching to Ubiquiti.  

Thanks Cisco.

[RickJames]

Well this thread makes me want to just cry. I just spent crazy amounts of money on this stuff only to learn ipv6 over vpn doesn't work so now i have a 10 thousand dollar utm that can't even provide a vpn? What the ...

Seriously meraki fix this like yesterday please. I can't even begin to explain my amazement by this whole situation. I feel like a complete moron for buying this thing. The AP's work fine but this is completely unacceptable for a device in this price range. I need to be able to provide a vpn through my utm. All I can say is i am not spending another penny on a meraki product until i see this resolved.

[nikiwaibel]

As of 2018: The lack of an IPv6 stack is a BUG, not a missing feature!!!

[micahawitt]

The very sad reality is that they want this as a push for you to buy asa's and more of the enterprise gear.  The also sad reality is that from a IT support as consultants or engineers, we love the dashboards and simplistic views and being able to manage on the fly with things.  Cisco is also getting a sh*&ton of $$ with either product that we are purchasing from them.

So please.  Implement it already.

[JPAWELCHAK]

---

@RickJames wrote:

Well this thread makes me want to just cry. I just spent crazy amounts of money on this stuff only to learn ipv6 over vpn doesn't work so now i have a 10 thousand dollar utm that can't even provide a vpn? What the ...

Seriously meraki fix this like yesterday please. I can't even begin to explain my amazement by this whole situation. I feel like a complete moron for buying this thing. The AP's work fine but this is completely unacceptable for a device in this price range. I need to be able to provide a vpn through my utm. All I can say is i am not spending another penny on a meraki product until i see this resolved.

---

If you purchased it less than 30 days ago request an RMA but be sure to tell them why you are doing so.

[nikiwaibel]

[nikiwaibel]

[nikiwaibel]

[MRCUR]

@nikiwaibel While I understand what you're going for, badgering Support about this isn't going to change anything right now. Make sure your sales team knows you want IPv6 support in the MX line so they can add your account ($$$) to the feature request. 

[adymeblack]

@MRCUR:

Badgering support would probably have a better result. The last people I would want to speak with is the Meraki Sales team. They probably don't know, or care, about the technical requirements of today. They are there to sell the product.

I personally would badger any and every soul that works @ Meraki about this.

These MX devices should have NEVER hit the public market without IPv6 support. Let alone all of the 'new' devices that STILL don't support it. How much use is that LTE connection going to be when more and more mobile ISP's are moving to IPv6 ONLY every day like T-Mobile?

I mean, for the love of god (or whatever deity you choose....or not), even Windows XP could support IPv6.

Also, just to throw it out there, IPv6 is a network standard, not a feature, and should be treated as such.

[JPAWELCHAK]

Not my intent to be disrespectful in suggesting this but this requires drastic measures at this point. Perhaps it's time to Contact Todd Nightingale is SVP, General Manager at Cisco Meraki since everyone below him in the Meraki organization has  ignored our cries for transparency on IPv6 or provided useless responses on the matter.

He has a profile on LinkedIn: https://www.linkedin.com/in/todd-nightingale-a106b510/

He is also on Twitter here: https://twitter.com/tnight?lang=en

Why introduce the new MX products supporting LTE when some carriers and ISP are only supporting IPv6 this late in the game? Meraki needs to focus their resources on fixing this IPv6 predicament NOT releasing new products.

[nikiwaibel]

@MRCUR: i disagree. sales, in my case, does actively ignore *all* my IPv6 comments. if there is a response, it is this: https://documentation.meraki.com/zGeneral_Administration/Other_Topics/IPv6_Device_Compatibility. i am pretty sure, most of sales have no clue what i am / we are talking about.

but, the support teams know ***exactly*** what i am / we are talking about! and they may have the power to raise a hand.

i see two possible reasons for this situation:

a) cisco wants to keep the meraki produkt line "low"; maybe irrelevant in the future. (meraki may have been seen as a real competition, so they acquired them back in 2012).

b) the hardware may be cheap/old and no IPv6 stacks are available. not sure, if all MR/MX/… run linux.

i hope i am wrong with both points.

at least, i did not get an immediate, standard answer to my last post in case 03249519. for the record: the lack of an IPv6 full stack is not a missing feature. that's a BUG!!!

i suggest, if anyone is still interested in meraki, open a supportcase (example above) and tweet/message Todd Nightingale, as @JPAWELCHAK suggests:

 Twitter: https://twitter.com/tnight

 LinkedIn: https://www.linkedin.com/in/todd-nightingale-a106b510/

if you want, also create a feature request / wish and contact sales. maybe that helps as well.

[Bovie2K]

I was told the hardware supports IPv6 but there are some current software packages they need to replace before they can support it.

[nikiwaibel]

@Bovie2K: that's great news. porting/extending/replacing/updating some packages may take some time and get the GUI and logic ready as well. i still have some hope, that they have already gotten the shouting and have some surprise for all of us in 2018.

[Owen]

I agree that it is a software issue rather than hardware, the hardware certainly supports it. The MX64 can be booted into the broadcom reference software image which supports IPv6. Even though the Z1 is EoL you can load openwrt onto it which runs IPv6 dual stack.

[nikiwaibel]

[smccloud]

Honestly, I don't care if the hardware supports it and they are just replacing packages at this point.  To me it sounds like more excuses.

[MRCUR]

I've been requesting this for a while now. Clearly not a priority for the MX team unfortunately. 

[aws_architect]

One year past  what about IPv6 ? 

Any ETA ?

Someone at meraki to give a bit of visibility to us ?

[JasonCampbell]

@davidvan You post on other threads but won't address rebuttal to your non-answer post from June. Can you please comment on posts made RE: IPv6 since your last post?

[davidvan]

@JasonCampbell Unfortunately, I'm hamstrung on talking internal R&D efforts in a public forum. My last response is all I discuss publicly at this point.

But, don't hesitate to continue to put pressure on us. As soon as I have any update for you on this, I will be sure to notify the community.

[Bovie2K]

@davidvan Thanks for the post. I understand you are limited on what can be said but I think this forum thread is enough to take back to management to show there is a real NEED and WANT for full IPv6 and NAT64 support from MX. Like I said in an earlier post it wouldn't please everyone but even a middle ground of the phone home still using IPv4 but the MX's at least having NAT64 support would be great in the nearer term.

Also not knowing is the worst. We don't know if its two years away or two months away. Some statement at all would be helpful.

Thanks

[davidvan]

@Bovie2K I understand your point not knowing, and i'll see what I can do. Do you have a Meraki sales representative you can contact and discuss this issue with?

[BBFred]

Please don't bother talking to your sales rep. since they know even less. Its a sales rep. why would it bother with technical stuff anyway.

[smccloud]

My sales rep has changed 3 times in under a year, makes it hard to develop a relationship. Plus, I got my setup free for attending webinars.

[Bovie2K]

@davidvan Yes I can ask my rep.

[Morgan]

This has become a problem for our customers that use the client VPN and have T-Mobile iOS devices. Since T-Mobile has moved to IPv6 only, and the iPhone's lack of CLAT support, the VPN client doesn't work.

[Bryan_Vukich]

I've been waiting for IPv6 support for years now, and there's been little or no apparent movement on it.  I'd be happy with a separate beta firmware branch that has it enabled even if it's a bit broken.

[BHC_RESORTS]

---

@Bryan_Vukich wrote:

I've been waiting for IPv6 support for years now, and there's been little or no apparent movement on it.  I'd be happy with a separate beta firmware branch that has it enabled even if it's a bit broken.

---

This. All of our WAN providers have IPv6 being given to us, and we can't use it.

[Bovie2K]

I'll second. The time has come for full IPv6 support.

[CharlieCrackle]

Yes much needed support.  Have to sell cisco solutions when customer need IPv6 which is more and more    Websites behind meraki need IPv6 support.   Would love to sell meraki solution

[Rol]

Fully agree... and if IPv6 is too complicated for Meraki's developers, they probably can get some help from Cisco dev. team 😉

Meraki, you've added the possibility to have an IPv6 to the Switches... now finish the work and add a full IPv6 support to the MX, the AP, ...

Rol.

[BHC_RESORTS]

At this point I'm genuinely curious about the lack of IPv6 support on the WAN for the MX series. They have expanded IPv6 support to much of the other product lines, yet it remains missing from the WAN side.

[MRCUR]

@BHC_RESORTS Agreed. I've been asking about it for a while now. Perhaps they're having a hard time making it Meraki simple to run dual-stack. 

[etamminga]

Can we get a formal statement from Meraki Product Manager on the lack of IPv6 support on the MX products? Is the PM listening in on this thread?

This is now more and more a must-have!

Regards,

Erik

[gutree]

Totally agree. Chasing them for a year now. Just cannot believe that this is so hard to develop. Every other plastic box has it.

[nikiwaibel]

agreed. especially for clientVPN.

[JPAWELCHAK]

Completely agree, especially for Client VPN.

Meraki MX Product Managers, why are you so silent on this topic? What is the point of having a "community" if you aren't going to update those of us deploying and managing Meraki based networks for our mutual customers? IPV6 has landed and you can't support it?

[Chris_M]

The main thing is IPv6 is supported on the CIsco platform, its adapting it for the Meraki Dashboard that takes an effort and they haven't informed us of their time/effort on this.

I really strongly recommend IPv6 implementation since more and more web resources are efficient via IPv6 due to NAT traversal that IPv4 has to perform.

[MRCUR]

---

@Chris_M wrote:

The main thing is IPv6 is supported on the CIsco platform, its adapting it for the Meraki Dashboard that takes an effort and they haven't informed us of their time/effort on this.

---

Just to be clear - the MX devices don't run IOS. 

[DataBitzNZ]

Does anyone have a update on this, and did anyone see this post below by chance then attend the webinar?

Also I see there is another quarterly update webinar coming up, maybe an opportunity to ask Meraki directly.

https://community.meraki.com/t5/Security-SD-WAN/MX100/m-p/7718/highlight/true#M1987
Correct @MRCUR IPv6 routing is not there now but being developed on the MX line.  @JeromeBL tune into a Meraki Quarterly or Meraki MX webinar and you can ask live Q&A.  For example there is an MX webinar coming up on Jan 4th.  https://meraki.cisco.com/webinars

[Chris_M]

I will be attending the quarterly update webinar. We'll see if anything being said there.

[Chris_M]

The quarterly update confirms that they are aware of the increasing request for IPv6. Some regions are becoming exclusively or dominantly IPv6 and a team is working on it but no projections at this time.

Its recommended to provide a use case so they can optimize their development process to fulfill our wishes.

[nikiwaibel]

use case: VPN clients with IPv6 only connectivity must be able to connect.

[MRCUR]

---

@Chris_M wrote:

Its recommended to provide a use case so they can optimize their development process to fulfill our wishes.

---

This sort of drives me nuts about the Meraki internal feature request process. What is the use case for IPv6 on the MX line (or ANY product line)? IPv6 connectivity is the use case. It's 2018. IPv6 is not new. It's widely available from the ISP side. 

Not everything can directly be tied to a specific sale or use case. The MX line is meant to be a modern UTM/firewall appliance... IPv6 should probably be part of the feature set. 

[Bovie2K]

@MRCUR Agreed. I heard MS's are getting IPv6 Routing and MR's already have some support its time for MX's to get full IPv6 support. Especially when cheap consumer routers are getting it.

I totally understand providing use cases to justify some feature requests but @MRCUR hits the nail with this one the use case is getting the support.

[BHC_RESORTS]

@MRCUR: Completely agree. Our ISPs offer us IPv6 and it would be great to offer it as well.

[BlakeRichardson]

I agree, other vendors have been offering this for a while now. I suggest we all go to our dashboard now and make a request for it, if you have already made a request do it again.

At the end of the day we need products that work for us and if Meraki won't listen they will lose business.

@MerakiDave @CarolineS Can you push this, the community have been asking for a long time now!

[MerakiDave]

ACK.  There will be some announcements coming up in the next month, unfortunately I don't think IPv6 for the MX is in the next batch of regular product/feature announcements.  But the fearute request is firmly in place.  Please do get your designs and use cases fed back through your Meraki sales team, they need to take any/all of your opportunities and add them to the Feature Request so things can be prioritized, and you may also be able to get on an early beta firmware when the time comes.

[BHC_RESORTS]

@MerakiDave IPv6 WAN support is really what is needed on our side. All of our upstream providers offer it. While we don't really have any plans for IPv6 port forwarding or anything like that ATM, offloading traffic to native IPv6 is just part of being a good netizen. We also like to support the broadest range of connectivity options we can.

[PiperHans]

We need IPv6 support for a customer solution to service the dual stack solution they are asking!

[rarodrigo]

Now the new year started and we continue without support of IPv6 in MX devices. All the provider are offering IPv6 and many sites working inside of this technology, as well as IPv6 traffic globally keep increasing.

We need has this support in order to increase customer support and increase installation and many countries. All vendor are accepting this feature. 

[Uberseehandel]

At the moment the MX range is like a premier league player's WAG. 

To explain, the northern county of Cheshire is is very pleasant and full of desirable properties (like Greenwich, or Scarsdale or Bronxville for East Coasters) so is choc full of flash money. Dry northern humour says of these otherwise admirable women, something along the lines of "that's all fur coat, no knickers" it is even in the Oxford dictionary.

Back to the MX, too much it doesn't do -

in no particular order and with no pretense at being comprehensive

• IGMP proxy (for multicast)
• can't provide access to Chromecast devices from a different VLAN (unlike Bonjour)
• no IPv6 (and don't even contemplate tunnelling, please)
• can't put a local IP address on WAN uplink
• no IKEv2 (forst published 2005 - Internet standard 2014)

as the dictionary definition says - Have an impressive or sophisticated appearance which belies the fact that there is nothing to substantiate it. The MX is in need of love and attention. Cisco manages to do it.

[BHC_RESORTS]

IGMP proxy (for multicast)

I'm curious on your use case for this. Hardly ever see multicast used in most environments.

[Uberseehandel]

---

@BHC_RESORTS wrote:
IGMP proxy (for multicast)

I'm curious on your use case for this. Hardly ever see multicast used in most environments.

---

@BHC_RESORTS

Well different technologies in different parts of the world.

In North America corporations make extensive use of video conferencing over internal networks. Multicast makes a lot of sense in this situation, it helps prevent duplicate streams overwhelming the network (not unlike Akamai). In Europe and East Asia a slightly different configuration is used to distribute premium subscription TV content. As the telcos, who also happen to be content distributors, like to make efficient use of their own networks, they chose to use multicast. These telcos, mostly the original PTT incumbents, also provide managed services. They need the equipment they use to provide and mange services to be able to handle fixed, mobile, VoIP, broadband and television subscriptions. If it can't do VoIP and television, it is not nearly as popular as it could be.

I will be watching the Winter Olympics live from Korea in 4K TV, not having multicast for something like that is very expensive for the carrier/ISP. The most popular sport on television in most of the world is football (soccer in the USA). The most watched leagues globally are the Champions League (top European teams) and the premier leagues of the UK, Germany, Spain, Italy and France, even in East Asia. Getting 4K TV is a big part of this.

Delivering managed services to bars with premium sport on TV is big and profitable business.

These premium services go beyond sports, so many professional practices will have multicast capability as part of their corporate infrastructure, but also they are able to handle the version that the subscription services make use of. Certainly I saw the the TV in the doctors waiting room showing multicast channels.

[ControlAltIT]

Yes!  We needed this like a year ago.  Most of our cell phone users can’t connect to the client VPN since carriers are switching to IPv6 only.  Please get this done Meraki!

[DHAnderson]

If Meraki is looking for a use case here is one:

The Meraki MX systems value manageability over connectivity as compared to all the other firewall vendors.  This puts them behind in basic functionality.  If you need or want IPV6, a Meraki MX is not for you.  Is that what the company really wants?

Why can Sonicwall, Cisco, Watchguard, Fortinet and others all support IPV6.  Does Meraki not understand that the IPV4 pool in the US was depleted last year?

[jhouts]

Agreed.  The phone carriers push out an update last week that broke our phone VPN's for all carriers except ATT.  This is directly impacting our business as our sales people can't VPN into our network to do their demos.  I am the | | close to telling Meraki to pick up their gear.  v6 is 15 years old and there is no excuse for lack of support.

[Uberseehandel]

---

@jhouts wrote:

Agreed.  The phone carriers push out an update last week that broke our phone VPN's for all carriers except ATT.  This is directly impacting our business as our sales people can't VPN into our network to do their demos.  I am the | | close to telling Meraki to pick up their gear.  v6 is 15 years old and there is no excuse for lack of support.

---

I can't find a flaw in your argument. The entire MX line probably needs replacement.

For our own distributed environment we are placing a BrandX gateway ahead of each MX because that gives us IPv6, hideous IoT and multicast coverage, that Meraki simply does not address.

If Meraki does come up with an MX alternative, I seriously hope that they adopt the principal of zonal security.

[FM]

You're right! It would be great if IPv6 is supported.

[edcho]

Has Meraki said anything officially or unofficially about this yet?

As more and more IPv6-only endpoints appear, it's becoming more of an issue everyday in various environments.

[MRCUR]

---

@edcho wrote:

Has Meraki said anything officially or unofficially about this yet? 

---

The MX team did mention that v6 is "on our roadmap" in the Quarterly Update yesterday. See here (33:05 timestamp): https://youtu.be/CBCTMh-h2zs?t=33m5s

[SDTHI]

I agree with this, awaiting response from Cisco Meraki due to VPN's breaking and support for IPv6.

[adymeblack]

I do find it a bit disappointing that for the price and everything else that these devices don't support IPv6.

These are supposed to be the best of the best yet can't handle IPv6.

[DHAnderson]

I would imagine adding support for IPV6 would be a full stack project the touches all parts of the architecture, so it not a task to jump into lightly.  That said, there are no more IPV4 addresses in the US, except at ISPs.  Any new technologies like 5G will need IPV6 addresses, so it high time for Meraki to be working actively on the issue.

It is good to hear that it is on the road map, but it would be better to know that there is a live project for it.

[TheOldGuy]

The T-Mobile IPV6 is going to cost a multi hundred device deal with a client of mine. We highly recommended Meraki a while back and the lack of support and the promise of it is coming but never being here has egg all over our faces.

[DarkStar]

We have just been notified by 2 of our rural ISPs that they will no longer be able to provide IPv4 addresses. They are such small ISPs that cannot keep IPv4 address space and will be converting everyone to IPv6 over the next 6 months. (Note these are the only ISPs available) This will not matter to their residential customers who just get a new modem and they work fine. BUT! We have MANY sites with MX devices that are critical to our business and the safety and well being of people in these areas. We do not have the money to replace all these devices with something else, not to mention it will break our VPN mesh. Meraki we need IPv6 support ASAP, we can no longer wait.

[JPAWELCHAK]

Meraki, your silence on this topic speaks volumes...

Surely your product managers are aware that IPV6 became a Draft Standard in December 1998, and became a ratified Internet standard on 14 July 2017. Service providers are already making the switch in a big way yet a "premium product" like Meraki doesn't support a ratified standard, it isn't as though this is all new at this point.  Products at a fraction of the cost already support it.What's the delay?

Meraki needs to stop being silent on this topic and inform your "valued partners" and proponents re IPV6 with more than a "its on our roadmap"

[TheOldGuy]

I have a meeting next week with a large gaming/hotel company that we are recommending to remove ALL Meraki and goto another solution immediately. They are looking at over ten thousand room's of hotel space and Meraki just doesn't give a hoot.

[davidvan]

Meraki is excited to bring lots of new features to market to delight our customers with a sophisticated feature set that has simplicity built-in. The MX team is aware of the request for IPV6, along with several other features that have been listed in this thread and elsewhere on the community. We appreciate everyone’s feedback, your “Make a Wish” requests on the dashboard, and coming to talk to us during trade shows. Thanks, and keep it coming!

I’d love to give you a peek into the Meraki magic happening behind the scenes to see what we have in store! Unfortunately, we generally do not comment publicly on our roadmap. Please get in touch with your Meraki representative for specific timelines for new features.

[JPAWELCHAK]

---

@davidvan wrote:

Meraki is excited to bring lots of new features to market to delight our customers with a sophisticated feature set that has simplicity built-in. The MX team is aware of the request for IPV6, along with several other features that have been listed in this thread and elsewhere on the community. We appreciate everyone’s feedback, your “Make a Wish” requests on the dashboard, and coming to talk to us during trade shows. Thanks, and keep it coming!

I’d love to give you a peek into the Meraki magic happening behind the scenes to see what we have in store! Unfortunately, we generally do not comment publicly on our roadmap. Please get in touch with your Meraki representative for specific timelines for new features.

---

@davidvan, this isn't at all helpful and is simply more of the same babble. May we suggest you laser focus on critical features like IPV6 Vs. the new fluff if not already doing so and put out an official statement and timeline for IPV6, you are about to haemorrhage partners and customers for not doing so. I've been a Product Manager and would have lost my job having missed critical deliverables as important as this. It's hardly new at this point and should be well beyond "Make a wish" and/or conversation at Cisco events. As for not commenting publicly, IPV6 isn't exactly a competitive advantage for Meraki at this point but rather a liability you need to address quickly.

[JPAWELCHAK]

---

@davidvan wrote:

Meraki is excited to bring lots of new features to market to delight our customers with a sophisticated feature set that has simplicity built-in. The MX team is aware of the request for IPV6, along with several other features that have been listed in this thread and elsewhere on the community. We appreciate everyone’s feedback, your “Make a Wish” requests on the dashboard, and coming to talk to us during trade shows. Thanks, and keep it coming!

I’d love to give you a peek into the Meraki magic happening behind the scenes to see what we have in store! Unfortunately, we generally do not comment publicly on our roadmap. Please get in touch with your Meraki representative for specific timelines for new features.

---

@davidvan, this isn't at all helpful and is simply more of the same babble. May we suggest you laser focus on critical features like IPV6 Vs. the new fluff if not already doing so and put out an official statement and timeline for IPV6, you are about to haemorrhage partners and customers for not doing so. I've been a Product Manager and would have lost my job having missed critical deliverables as important as this. It's hardly new at this point and should be well beyond "Make a wish" and/or conversation at Cisco events. As for not commenting publicly, IPV6 isn't exactly a competitive advantage for Meraki at this point but rather a liability you need to address quickly. Admit you've messed up and tell us how/when you are going to fix it.

[adymeblack]

I can't agree with @JPAWELCHAK more. It's all more of the same "no-answer" answers. 

This isn't some new technology that no one else knows about or is proprietary to Cisco/Meraki. It is literally a 'standard' in networking technology and has been for years.

[MRCUR]

@davidvan Wow - that is not the kind of comment anyone is looking for from a Meraki employee on the topic of IPv6. If all Meraki has to say is "Keep making wishes!", this is probably not the thread to come say that in. This is not what I have come to expect from Meraki and am really disappointed by this kind of commentary from an employee. 

[TheOldGuy]

What a joke and a disgrace! I think that we will move from not recommending to active removal with attitude like that!

[DHAnderson]

I agree that the Meraki response was beyond awful for a core networking technology.

I think that it is time to jump off this board and start calling your sales reps and letting them know we need more information.

The more wood we can throw on this fire, the better we will get noticed and get answers.

[grimm_j]

It's not critical for us now but this seems like a basic requirement that should be implemented shortly. 

[Chris_M]

@grimm_j Unfortunately, it is critical. The Internet infrastructure has changed so much that many service providers are going full IPv6. This becomes very important, especially organizations that are at the cutting edge pushing the boundaries of technology. IPv6 is a requirement and whats holding Meraki back is their security appliance not supporting IPv6 yet.

[smccloud]

I have run into issues with the lack of IPv6 both at home and at work.  I have an iPhone on T-Mobile and they do not hand out IPv4 to their phones anymore.  Means I can't connect to my work VPN or my home VPN.

[Bovie2K]

Its not just that they don't have IPv6 its the total radio silence. Not even a we are working on it and expect it by Q whatever 18 or 19. Even if they added it as supportable but still needed IPv4 in the short term to phone home that would be preferable to no IPv6 support period.

I would also echo the other comments in this thread that Meraki employees quit calling it a feature. When everyone else supports its no longer a feature its a basic requirement.

[smccloud]

@Bovie2K I agree.  I just rolled out internal IPv6 at the office but had to get an internal only IPv6 range.  I know both the ISP we have at work and the ISP I have at home support IPv6.  One via static allocation (I believe), the other via IPv6-PD.  I want both to work since I am he.net IPv6 certified.

[JPAWELCHAK]

---

@Bovie2K wrote:

Its not just that they don't have IPv6 its the total radio silence. Not even a we are working on it and expect it by Q whatever 18 or 19. Even if they added it as supportable but still needed IPv4 in the short term to phone home that would be preferable to no IPv6 support period.

I would also echo the other comments in this thread that Meraki employees quit calling it a feature. When everyone else supports its no longer a feature its a basic requirement.

---

@CarolineS What makes Meraki's radio silence on IPv6 even worse is that they would reference this thread as one that I assume Meraki is taking flack on in the community birthday announcement sent out yesterday yet continue to stand on their non-answer answers. It screams "we hear you but don't really care" and demonstrates how tone deaf Meraki is on this issue. It's shameful and borders on irresponsible!

We ask again... When is Cisco Meraki rolling out support of IPv6 on the MX and the rest of the Meraki network stack in beta and when is Meraki hoping to have it into stable release? "We continue to chip away at IPv6" during Meraki's quarterly update webcasts is not a suitable response to an important question.

[adymeblack]

Its kind of a bummer to think that so many users are so close to pulling all Meraki equipment and they (both the user and Meraki) will lose so much money over a standard protocol like IPV6.

How long do you think the iPhone would last if Apple suddenly decided it doesnt need a standard web browser anymore?

[nikiwaibel]

this article is in german: https://www.heise.de/newsticker/meldung/IPv4-Daemmerung-Telekom-testet-IPv6-only-Kommunikation-im-Mo...

the message ist very clear: IPv6 is already there, also in europe/germany. IPv6 only is being tested. it is the future. RIP IPv4 and - hopefully(!) - not meraki.

[smccloud]

I hate to say it, but I'm about to switch my router to something that supports IPv6 PD and just keep my switch and AP.

[JPAWELCHAK]

@davidvan I know you are likely still feeling a bit of a sting from the replies to your last response re IPv6 on this post (sorry for that) but you still have a "community" looking for Meraki's guidance re the IPv6 standard which was fully ratified LAST YEAR and that Cisco Meraki still does not support. Therefore, we ask again and request a more appropriate and productive response than we received last time to the simple question: When is Cisco Meraki rolling out support of IPv6 on the MX and the rest of the Meraki network stack in beta and when is Meraki hoping to have it into stable release?

If Meraki isn't going to provide honest and transparent answers to the questions people have on the matter why even bother with this community? Again, IPv6 isn't a competitive advantage Meraki needs to hide from the world while in development, it's a requirement that both partners and customers need to be kept informed on.

[smccloud]

I am regretting making the choice of a Meraki MX64 at work due to this.  I wanted to start rolling out IPv6 but I can't since they don't support it.

[Chris_M]

Hopefully, but doubtful on my part, the quarterly update tomorrow will give us something on this front.

[TheOldGuy]

We are regretting even breathing the word Meraki, it has cost us two clients just due to this one issue.

[DHAnderson]

I just attended to quarterly Webinar.

IPV6 ACL in MS series is the closest to any real talk about IPV6.  In response to questions about IPV6, the response was that they are "continually chipping away at IPV6".

To change the chipping away to a commitment the community needs to step up and:

1. Call your sales rep and tell then IPV6 in MX is critical.  Keep calling!
2. Continually click the Make a Wish on the MX page and enter IPV6 with a reason of why it is needed.
3. Attend the quarterly meetings and ask about MX IPV6.  

We need to stop complaining to ourselves and ramp up our complaining the Meraki directly every chance we get.

[smccloud]

Let my sales rep know I need it at home and at work, he got promoted so he sent it to my new sales rep (I think he was my rep for a month).  Honestly, at this point I will probably rip out all my Meraki gear at home and deploy new Ubiquiti gear (since I gave my old Ubiquiti gear to my parents when I got my Meraki stack).

[ScubaSteve]

We are in somewhat of the same boat. We have spent well over 50k on devices and licensing. Our ISP has no more IPv4 to hand out. Some of our servers require it such as Micrsoft's DirectAccess. 

I am deeply saddened that Meraki is not more transparent on this issue. Even something as much as we are almost done, expect it sometime next year would suffice.

At this time if we don't see something by the end of the year we will have to switch to something like SonicWall.

Very sad Meraki. As others have stated this is a feature that has been out on even the cheapest routers and firewalls for a long time. Yet Meraki can't seem to get this deployed? I am almost positive they probably have 1 or 2 guys working on this while the rest are working on the billions of beta firmware they seem to have.

[TI_Master]

I will chime in with this as well, we have a deployed fleet of MX's across several states/locations.  And I live in fear of at least one of them deciding to force IPv6 on us at one of the various ISP's.

[TheOldGuy]

Yeah TL I know what you mean, my nightmare of losing an almost 7 figure a year client came true last week due to Meraki sitting on their arse about this. They are blaming us and talking about a lawsuit. 

[Austin]

We're a startup, setting up our corporate and service network and I need to expose some servers for public access. We have restricted IPv4 space from ISP, so I decide to learn about IPv6. Become IPv6 master (okay, not quite, but much more educated now). I decide IPv6 is the right answer for many challenges we're facing, so I log into my Meraki dashboard to implement IPv6 on MX, MS, and MR. Don't see any options in the menus; decide to find instructions online. Find this thread instead. 

Next step: change our network infrastructure?

[JPAWELCHAK]

---

@Austin wrote:

We're a startup, setting up our corporate and service network and I need to expose some servers for public access. We have restricted IPv4 space from ISP, so I decide to learn about IPv6. Become IPv6 master (okay, not quite, but much more educated now). I decide IPv6 is the right answer for many challenges we're facing, so I log into my Meraki dashboard to implement IPv6 on MX, MS, and MR. Don't see any options in the menus; decide to find instructions online. Find this thread instead. 

Next step: change our network infrastructure?

---

@Austin if you are looking for a response from Cisco Meraki on this don’t hold your breath. All they do is respond with canned non-answer responses and direct you to your Meraki rep. who  I followed up with but they only give the same useless response those Meraki staff in the community give. Both Meraki senior management and Cisco senior management all have public social media accounts (Twitter). It may be time to be reaching out to them directly. My account rep ageeed that might be a good approach since their hands are tied. The current situation is unacceptable.

[nikiwaibel]

@JPAWELCHAK: i also do think it's time to make this issue public. nothing happens if we continue here on this thread. which twitter accouts shall we write to?

[JPAWELCHAK]

IPv6 needed

[nikiwaibel]

@meraki_ #ipv6now https://community.meraki.com/t5/Security-SD-WAN/WE-Need-IPV6-Support-in-MX/m-p/28756 @cwstori @tnight @ChuckRobbins

[pstewart]

I'm massively disappointed about lack of IPv6 as a new Meraki customer.  It was a choice between Meraki and Juniper Sky Enterprise - wondering now if I made a big mistake.

[TheOldGuy]

@Austin You hit the nail on the head if you need IPv6 then you have to change infrastructure which is what we are recommending to anyone using anything Meraki. This disgusts me and has left a huge black mark on my company for recommending this stuff. 

[Daghan]

I run part of Meraki Product Management that includes MX.

We agree (PM / Eng teams) with everyone on this list that we need IPv6 and we need it yesterday! 

There is nothing sinister about the delay. It isn't a hardware limitation, nor a Cisco ploy to drive a wedge between Meraki and Enterprise Networking products. In fact, we have engineers working on IPv6 right now and we are in the process of formulating an accurate roadmap. I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when. 

What is taking us this long?

When I launched MX with 2 engineers 8 years ago, we were the little engine that could. One strategy we adopted was to "fit the use-case", not to build generic features. Well, in some instances, we overfitted some of those use-cases that created technical debt. We had no clue that we had to worry about it. If someone came to me in 2011 and said you'll sell 1M MX in the next 8 years, I would have asked which psychedelic drug there were on.

But it happened!  We are energetically trying to redo some of our earlier decisions (network objects, n uplinks, no-nat, full support for BGP...are some highlights from our infinitely long to-do list).

None of the above is an excuse, but I wanted to shine the light of transparency on our thought process. 

To remain a strong (we are in fact 14K customers strong) SD-WAN provider, we have to put IPv6 behind us... and we will.

Thanks,

Daghan.

[TheOldGuy]

too little too late

[Austin]

Hello Daghan,

Thanks for the feedback; I appreciate it. Glad you understand our need, just wish the implementation could happen sooner.

I look forward to further updates. 

[smccloud]

Daghan,

One thing that would help a lot is if you can provide at least relatively regular status updates. I would like to be able to use PVv6-PD at home and also get IPv6 rolled out at work.

[Daghan]

I think that is a great suggestion, I'll make sure the community gets regular updates.

[Uberseehandel]

---

@Daghan wrote:
I think that is a great suggestion, I'll make sure the community gets regular updates.

---

Sadly, regular is one of those warm fuzzy words that doesn't actually mean anything.

In case the engineers have overlooked it, how is development of the MX's Multicast capability, and most importantly, an IGMP Proxy because more and more content providers are depending upon this for distribution to end users. Any number of home networking routers can handle this, why not Meraki?

[JPAWELCHAK]

---

@Daghan wrote:

I run part of Meraki Product Management that includes MX.

We agree (PM / Eng teams) with everyone on this list that we need IPv6 and we need it yesterday! 

There is nothing sinister about the delay. It isn't a hardware limitation, nor a Cisco ploy to drive a wedge between Meraki and Enterprise Networking products. In fact, we have engineers working on IPv6 right now and we are in the process of formulating an accurate roadmap. I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when. 

What is taking us this long?

When I launched MX with 2 engineers 8 years ago, we were the little engine that could. One strategy we adopted was to "fit the use-case", not to build generic features. Well, in some instances, we overfitted some of those use-cases that created technical debt. We had no clue that we had to worry about it. If someone came to me in 2011 and said you'll sell 1M MX in the next 8 years, I would have asked which psychedelic drug there were on.

But it happened!  We are energetically trying to redo some of our earlier decisions (network objects, n uplinks, no-nat, full support for BGP...are some highlights from our infinitely long to-do list).

None of the above is an excuse, but I wanted to shine the light of transparency on our thought process. 

To remain a strong (we are in fact 14K customers strong) SD-WAN provider, we have to put IPv6 behind us... and we will.

Thanks,

Daghan.

---

@Daghan  Thank you for this. I would have hoped that having seen this thread you would have been a little more concrete than this. Despite being a step in the right direction this response too comes across as more of the same non-answer answers to a certain degree and I find 3-6 months to have a roadmap you can communicate more than concerning. Again, IPv6 has been ratified for some time, should you not already be well ahead of this by this time? If not, then Meraki has failed horribly at delivering on the critical support of a STANDARD not a nice to have FEATURE everyone at Meraki seems to treat IPv6 as.

We are well past these sorts of vague and long past due responses. Please make this right and provide concrete details and timelines you surely have by now, how could you not?

[Mitch_Hennessy]

In this case, I could see why they wouldn't commit to a time frame, because IPv6, as it turns out, is kind of a mess, and is a mess in specific instances, a lot of which probably apply to a lot of Meraki (and Meraki-only) networks.

How do you define "support in MX"?

A lot of the mess is trying to force IPv6 into a NATed IPv4 world of today.  v6 is old (first draft was back in '98), but only just received standardization last year, and there are still issues that IPv6 only networks don't address or have agreed upon solutions for -- many of which probably apply heavily to Meraki networks, like multi-homing and source address selection.

Not to defend Meraki here or absolve them of any culpability, because while MXes are nifty for what they're really good at, they're extremely frustrating to work with at times, especially in mixed vendor or mixed-grade environments. I still don't see why I can't use AnyConnect with an AutoVPN spoke MX directly instead of a hub, because I don't, in fact, want to full tunnel all my traffic through an AutoVPN hub just to get back out to the Internet or to reach other routes behind an MX. I wish OSFP was bi-directional. I wish there was an inbound site-to-site firewall config in the Dashboard. I wish I can selectively choose which networks or VLANs I want to do L2 tracking on, because I may have a L3 core switch connected between a client LAN and the Meraki (which is in my transit VLAN), but also use the MX itself for a guest network -- so I have to choose either incorrect L2 tracking info for my internal LAN or generic L3 tracking info for it and then Active Directory group policies don't track properly. I wish I could do overlapping AutoVPN networks in NAT mode. I REALLY wish you can specify backup peer IPs for non-Meraki VPN peers (like in ASAs crypto maps or...really any other vendor VPN configuration) -- especially when trying to use S2S VPN to non-Org MXes that are in NAT mode with dual uplinks for high-availability.  I've made these wishes in the Dashboard "Make a wish" and am still waiting.

But what it is designed for, it does very well. I have to admit that. AutoVPN and multi-homing are more the MX wheelhouse (as it were). If you own both sides of the Meraki VPN tunnel, and put 'em in the same Org? One of the better things since sliced butter. When you try to deviate from the "Meraki way" for any real reason is when you run into frustrations. And I've run into a lot of them. And in a lot of cases, had to learn to either work around them, tolerate them or re-engineer it entirely. I'm not always successful.

I wish for a lot of things from an MX that might've been unfair to expect or "demand" in a device that was just simply trying to fill in a niche and do a specific job. In retrospect, it might've been too much to expect to be able to do a drop-in replacement of other types of equipment for specific tasks. It leaves a lot to be desired for granular control over remote access VPNs -- I can't treat is like AnyConnect Dynamic Access Policies or tunnel groups that are AD group authenticated and allowing for "blacklist" groups.

I went to the Meraki Lab training in NYC back in January of this year, took and passed the CMNO (I'd been working with it for a while by then) and then waited until most other attendees left and absolutely assaulted (pestering questions) my sales rep (who was there administering the exam and knew I'd be attending ahead of time -- good of him not to try to dodge me when he saw me) with the issues I just listed above and what Meraki plans on doing about it.

I say all of that to espouse the fact that I'm not at all a "Meraki Shill" as I'm sure some may be thinking if you made it this far, but to say that while IPv6 seems simple to do, it's deceptively complicated or at least can be depending on your network(s) setup. And that's before you even package an interface around it and inject it into the current Meraki Dashboard "single pane of glass" interface. If you're already familiar with PI vs PA, NPTv6, NAT66, NAT64, Multihoming, GUA/LLA/ULA prefix renumbering and prefix delegation, I apologize if I get things wrong (I'm typing this from my understanding of everything), and please bear with me.

You might say "other vendors can do IPv6, why can't Meraki?" Valid question, but the nuances of how IPv6 is designed to work don't exactly make it a drop-in replacement for IPv4 public IP space. I've read a lot of IETF RFCs, and some brilliant blogs of people far more educated in the topic than I regarding IPv6 in a NATed IPv4 Internet.

The reality of today is that most of the Internet is NATed (for better or worse), a lot of applications that used to break in the early days of Dynamic PAT (like VoIP/SIP) found work-arounds or were re-engineered entirely to traverse a NAT boundary. If you don't get a static allocation (single IP, /29 or /27 usually) from your ISP or apply to get your own Provider-Independent (PI) static address space (/24 at minimum) and ASN to advertise your static block via BGP with upstream providers, you're usually given a dynamic IP address from your ISP, especially if you're a residential customer or business class (non-Enterprise) customer in a lot of markets. Modern IPv4 networks deal with that by NAT, so if the IP changes, you normally don't care, because your private subnet(s) never change/changes and DDNS makes tracking the changes from outside trivial. NAT, for all its "evils", made renumbering private networks more or less a thing of the past unless you had to merge remote private networks and both sides had the unfortunate luck of using default prefixes (192.168.0/1.x). Said another way, your private LAN address space is yours in the context of just your LAN. RFC1918 to the rescue.

That's not the case with IPv6. IPv6 was originally designed and planned for during the days you could receive a public allocation of a /16 or a /24 from an ISP and you owned that address (no givesees-backsees) for all intents and purposes, where unique end-to-end addressability was not only feasible, it was the reality at the time. So, of course, v6 went for the same end goal originally, but using an almost impossibly high address space as to make exhaustion unlikely in any future where humanity still exists.  The problem was that while waiting for this to finalize, the rest of reality dealt with exhaustion another way and the modern Internet now looks architecturally different to what it was when IPv6 was originally designed.  This means that, even to this day, proponents of "pure" IPv6 wanted no NAT at all in the final specification and shun any mention of it in discussions or any suggested RFCs are unequivocally "rejected". In some ways it's almost as bad as Apple vs Android debates (in that people more or less tend to remain civil), and in other (more important, policy-influencing) ways, it's worse, because the scope is just THAT much greater. It's almost self-defeating; you're told to get rid of your IPv4 habits when it comes to IPv6, but then in order to dual-stack (which we've been doing and will continue to need to for quite some time), you kinda have to force both to coincide on the same network.

So. To the point. Your ISP offers dynamic IPv6 prefixes. Cool. You then take that IPv6 address prefix and then NAT all your devices/VLANs to it (Dynamic PAT/1:Many NAT) like you do with a public IPv4 address, right?

No. Or I guess "not quite". That's not how it's designed to work.  In theory it could if your ISP supported NAT46.  Maybe.

They assign you a /64 to your WAN interface, which is a lot of address space, but the kicker is, it's only meant for a single (V)LAN. If your Meraki has VLANs (and a lot of networks do, because why not?), that /64 is only usable by one of those VLANs. You're never meant to break up a /64 (VLSM) into longer prefixes (smaller networks) for your VLAN SVIs, and in doing so, SLAAC stops working (depending on how it's implemented in the client OS). So now you have to choose whether your computers get IPv6 Internet access or your phones do or do your guest WLAN gets v6 access. That's not a show-stopper if your ISP will also assign you a /60, /56 or /48, and you're still getting an IPv4 address, but you're generally not in control over that. If an ISP doesn't offer any prefix range larger (shorter prefix length) than a /64, you're kinda out of luck.

But then you might say "T-Mobile does it just fine!". Yes, but your phone is connecting directly to their LTE network -- they were already assigned a (or several) /32(s) prefix(es) by RIRs a while back. Your phone is simply sharing their address prefixes and they have policies to then route you out to the Internet from there. Your phone isn't meant to be part of a broadcast L2 LTE network like a private LAN, nor was it meant to accept unsolicited connections from the outside over LTE because each device is supposed to be its own "island". Direct IPv6 cutover makes plenty of sense for mobile operators of 3G-5G networks because of how the devices and network access is structured.

Okay, so let's say you're a VERY simple Dashboard Network; you have a single flat LAN and you use Google Public DNS for all your LAN devices. A /64 works just fine, except, again, no NAT, so your internal address space is (ignoring IPv4), dual-numbered. You have your Link-Local IPv6 addresses (fe80::/10) and you also have a Global Unicast Address inside your network, based on your ISP-assigned prefix. If that prefix changes because your modem and/or Meraki reboot (scheduled firmware upgrade?) so does your GUA prefix addresses on ALL of your LAN devices. Again, not really a show-stopper with Neighbor Discovery and DDNS if you don't have internal DNS name caching, and you don't run a domain at home. You can use your non-changing link-local address to reach everything else on your network if you really needed to. Maybe the Meraki itself keeps a record of hostnames to SLAAC/DHCPv6 addresses so you can reach your Plex PC from your phone or your other laptops or something -- I'm not sure how they'd implement that, because ARP isn't used in v6 networks and I don't personally know enough about how Neighbor Solicitation works to even suggest a Dashboard interface for it.

Let's scale this up a bit. You're a slightly advanced single site with two VLANs, one for PCs that do IDS/IPS inspection and one for VoIP where you don't have an onsite IP PBX or some kind of on-site call manager, where your VoIP VLAN is excluded from stateful IDS/IPS inspection or global firewall rules because it's just VoIP, right? Your ISP is out of addressable IPv4 allocations, so they ONLY give you an IPv6 prefix that's a /64. You already know (from above) that you'd need either a /60, /56 or /48 in order for both VLANs to get access to the v6 Internet, so you request one from your ISP, but they have a policy that all residential accounts only receive a dynamic /64. Now you have to choose which VLAN actually gets Internet access, or you could re-engineer your network, put everything on the same VLAN and make your phone(s) static v6 addresses that are excluded from AMP inspection (and ignores default L3/L7 FW rules) by putting them in a different group policy. Now everything works. Until your ISP changes your prefix address and your firewall rules based on now invalid statics no longer apply.

Let's scale this up to what I think of as Meraki's target audience -- the SMB market.  The shops that have enterprise aspirations, with residential options for Internet.  They can't get an ARIN allocation from an LIR sponsor, they don't have their own ASN to advertise their non-existent allocation upstream via BGP and they may or may not get a static block of IPs  They want Internet high-availability or AutoVPN failover-ability, so they get two DIA broadband accounts from two different ISPs, but in this case, ISP1 (Comcast, for example), offers business class Internet with a static IPv4 (or a /29), but dynamic /56 prefix delegation (because, again, you don't own it, Comcast does) that they may or may not make a DHCPv6-PD DUID reservation for so you may or may not keep that reservation on your gear.  In the current IPv4 world (the world in which Meraki found their niche), it doesn't really matter -- your public IP address has little to no bearing on which RFC1918 address space you choose to subnet your network from.  In the IPv6 world, it does matter, because that prefix is now what's assigned as the GUA to all your LAN devices, and if it changes, your LAN devices require renumbering.  At least if they plan on communicating via their GUA prefixes.  How does the Meraki decide which /64 prefix to assign to which VLAN interface from your /56 prefix WAN delegation?  If you statically assign the VLAN interface IP (like you would for IPv4 RFC1918 addressing) from the existing prefix, what do you do when it changes and that static prefix is no longer valid?  How do you make that Dashboard-able?

For dual-uplink networks, which I'm guessing a lot of Meraki networks are, you have the issue of source address selection; your devices LAN interfaces will receive GUAs from both prefixes at the same time, so now your devices have to decide which GUA prefix to source Internet traffic from.  Or maybe you decide "whatever, I'll roll out ULA" (which, again, IPv6 camps either support or decry and there are no OS vendor recommendations on the subject as to what's best-practices because ULA addresses are kinda sorta almost analogous to RFC1918 addresses).  Then the question becomes to do NPTv6 your ULA address space or split domain your GUAs for Internet traffic and only use ULA for local domain traffic?  Does your OS know how and when to use which ones?  What order does Windows 8.1 or Windows 10 choose when selecting v6 address preference?

Merakis handle uplink statuses and failover pretty well, but there is no yet fully-agreed-upon consensus on how to deal with IPv6 multi-homing or how it reacts when a prefix becomes unavailable because one of your ISP connections are down.  DHCPv6 and SLAAC weren't ever designed to work with Meraki devices that didn't (or weren't that pervasive) when the protocols were developed, and if Meraki goes their own way with a solution that's not "to-spec", then they'll catch grief for that.

Ivan Pepelnjak summarizes the point much better than I ever could in his ipSpace blog here.  That post was from 2015, and, to date, to the best of my knowledge, there still isn't an agreed upon consensus on how to handle or mitigate the issue(s) it bring(s) up.

This entire IPv6 saga is kind of a mess for how the Internet of today is -- on one hand, you have a group of people hell-bent on returning the Internet to "how it was before NAT" and, in only a few instances, grudingly accept that some concessions have to be made for how networks have evolved these days (but will often repeat "NAT IS NOT SECURITY AND IT SHOULD DIE A HORRIBLE DEATH!!!"), and there's another side; a group of people that just want to do a drop-in replacement of IPv4, NAT66 (RFC4864) and all, and both sides of the table have influence on the IETF...at least to some degree.  And a third side that says "hey, so why don't we at least let those who need it do prefix translation?", which is NPTv6, where it's still 1:1 mapping, no port overload, but those in the first group consider that almost (if not just) as bad as NAT66.  There are a staggering number of RFCs floating around, some of which I'm sure supersede other earlier ones that at least try to offer a way to mitigate issues that an IPv6 network would face that a NATed IPv4 network doesn't care about.  But nothing's finalized.  And that's the hard part.  As an equipment provider, what do you do during a transition period?  Especially one this broad?  This is like the 802.11 pre-draft-N situation raised to the 128th power. 

I come full circle to why I typed this out:  if you genuinely require IPv6 pure Internet access, then Meraki isn't currently for you.  In their shoes I wouldn't ever want to promise a timeline that might change on the whim of a new RFC or an IETF policy that would make my devices then out-of-spec and then have to hear those complaints.

I urge everyone in this thread to please read up more on the current state of IPv6.  It has been and still is quite a saga.

Meraki has a choice:  Do they roll out some form of IPv6 routing support in NAT mode, which may or may not solve anyone's problems?  Do they try to get a framework going where it's supportable for their larger network customers first, and then let that trickle down to the smaller single LAN networks?  That would take longer, but it would affect a larger number of people at once.  How long do they give themselves before committing to a timeline?  How forgiving do they think their customers are for changing (or missed) timelines?

But like I said, I'm not trying to absolve them of any and all culpability, they could have issued a press release that listed everything I just did above to at least give their customers a sense of the scale this issue presents.  Many of their target audience are people who don't have a deep background in IT and choose Meraki for ease of administration, but the problem is, IPv6 administration, as it stands today, is anything but.

Make the interface too "difficult" and you risk alienating the people you were trying to help by "Meraki-ifying" their network (and removing one of the driving motivators for them choosing Meraki in the first place).  Make it too "simple", and you miss out on nuance and configuration options for specific networks that may or may not require ULAs to function or NPTv6 (not even Cisco really has it down on anything other than ASRs/CSRs and ISRs) or NAT66 or how to design an interface that guides you on making firewall rules for remote networks that might still be reachable (at least routable due to publically routable GUAs) when AutoVPN is down or if it fails "closed' or "open", or how DHCPv6-PD and SLAAC behave during an uplink outage and, and, and, and, and...

This was long to type, as I'm sure it's long to read.  And I just scratched the proverbial surface when it comes to IPv6 and it took all these words to form a cogent thought train.

If you made it this far, congratulations.  I tip my hat to you.

[ControlAltIT]

That’s a very well written summary of the state of affairs with IPv6.  I think the most practical need for IPv6 for Meraki SMB customers is client VPN support for folks on cellular networks like T-Mobile that are IPv6 only.

[Mitch_Hennessy]

---

@ControlAltIT wrote:

That’s a very well written summary of the state of affairs with IPv6.  I think the most practical need for IPv6 for Meraki SMB customers is client VPN support for folks on cellular networks like T-Mobile that are IPv6 only.

I wouldn't begin to try to guess what is the most practical for anyone else's network, much less anyone else's Meraki network.  I can only speak for what I'd need for my Org (which is rather large and, as of yet, does not face this issue).  That doesn't remove the immediate need you have for your use cases.

But I guess that goes back to the whole decision tree Meraki has to make, doesn't it?  Even ignoring all the other variables of IPv6 on local networks and your ISP does assign routable v6 prefixes.  That only solves that one particular issue.  Others might be just as frustrated that such a change still does nothing for them.  What of those whose ISPs don't have routable v6 allocations to assign or require their customers upgrade to business plans they don't want to (or can't) pay for?  They're still out of luck.

Verizon wireless assigns my LTE devices fully routable v6 addresses from their prefixes as well, but also CG-NATs me through their v4 address space so that I can still reach v4-only public Internet resources.  I can still AnyConnect into my ASA at home because I'm still dual-stacked.  Maybe ask T-Mobile if they'd re-dual-stack your account again?  I don't know.  I have no answers that would apply to all cases.  I don't think anyone (or any one company) does.

Again, back to my point of being an unenviable position to find yourself in.

I'm sincerely not trying to start an argument or downplay the issues thread members face, I'm just saying I think a lot of players (ISPs, RIRs, edge network operators, OS vendors, mobile network operators) are still trying to figure it all out in the dual-stacked world we may find ourselves in for the foreseeable future.  It'll get better as time goes on; it has to.  But "as time goes on" does nothing for those stuck in this issue right now.

[HenryS]

Yes. I need my users that happen to be on IPv6 to connect to our VPN. I have no control over the end user's IP address. But I am losing billable hours when someone cannot work. The lost productivity will make the business case for switching.

[Djsky123]

This really needs to be addressed by Cisco. We implemented Meraki just under a year ago for our network for the main reason of being able to vpn into our network from iOS devices, and now that since iOS 12, the clients are being forced onto ipv6 addresses, they can no longer connect to our MX64 to access the network!

[stefann]

As everyone else has said, we need IPv6 support yesterday!

Our ISP has grown rapidly in the last years, and have been forced to move their customers behind CGNAT for IPv4 by default due to limited address space. We are luckily able to request an exemption to retain a routable IPv4 address, but these exemptions won't be available when they run out of address space!

[JohnM]

Don't worry, according to the earlier post they're just 3 or 4 months away!.... from maybe announcing a possible roadmap for future development... maybe. 

(Of course, as is the custom, it'll only be in restricted beta firmware for 12-18 months after a year of development)

[DHAnderson]

I have verified that my MS220-8P and MR33 all respond properly to IPV6 router announcements and can get a /64  address. 

I would be more than happy to to try beta MX IPV6 code to further the cause.

[smccloud]

Any update from Meraki on this or is it back to being in the dark after being promised timely updates?

[pstewart]

"A lot of the mess is trying to force IPv6 into a NATed IPv4 world of today.  v6 is old (first draft was back in '98), but only just received standardization last year, and there are still issues that IPv6 only networks don't address or have agreed upon solutions for -- many of which probably apply heavily to Meraki networks, like multi-homing and source address selection."

I'm a huge proponent of IPv6 and massively disappointed that Meraki isn't willing to adopt it a few years ago when I strongly feel they should have at a minimum.

Unsure what the "mess" is about though .. I see it deployed at scale in various networks every day.  By deployed, I mean in a dual stack specifically which allows for a transition path fairly easily when the day, in theory, comes to shutdown IPv4.  I'm not a fan of anything other than dual-stack ... all the transition technologies come with a certain degree of pain.

Also, with regards to standardization I'm not sure what you are referring to with regarding last year.  It's been a ratified and adopted standard for many years now - I first started deploying IPv6 into enterprise and service provider networks back in 2008 ... 10 years ago.

Just some two cents on your post ...

Paul

[DHAnderson]

I also have been working with IPV6 for a few years now, and I am disappointed with Meraki's foot dragging on this.

About a year  ago, I had a SonicWall TZ 300 (rough equivalent to a MX64) connected to Charter's dual stack cable network.  In testing, I was able to request and receive /62 and/60 subnets, so I could have separate address pools for separate VLans.  No NAT needed.  My MR33s we're able to respond to IPV6 router advertisements to get  an IPV6 from the SonicWall, and pass through IPV6 router advertisements to connected devices.  I could get to both IPV4 and IPV6 sites.

Cisco ASA, SonicWall, Fortigate and many more firewall manufactures all support IPV6.  There is no reason why Meraki couldn't have done this before now, other than different priorities.

Meraki needs to implement a basic IPV6 stack and leave out all transitionary technology to start. Get that into the hands of outside beta testers, while Meraki works on filling out more of the protocol requirements.

[Mitch_Hennessy]

---

@DHAnderson wrote:

I also have been working with IPV6 for a few years now, and I am disappointed with Meraki's foot dragging on this.

About a year  ago, I had a SonicWall TZ 300 (rough equivalent to a MX64) connected to Charter's dual stack cable network.  In testing, I was able to request and receive /62 and/60 subnets, so I could have separate address pools for separate VLans.  No NAT needed.  My MR33s we're able to respond to IPV6 router advertisements to get  an IPV6 from the SonicWall, and pass through IPV6 router advertisements to connected devices.  I could get to both IPV4 and IPV6 sites.

Cisco ASA, SonicWall, Fortigate and many more firewall manufactures all support IPV6.  There is no reason why Meraki couldn't have done this before now, other than different priorities.

Meraki needs to implement a basic IPV6 stack and leave out all transitionary technology to start. Get that into the hands of outside beta testers, while Meraki works on filling out more of the protocol requirements.

Yeah, if you luck out and have an ISP that knows what they're doing, it works.  Incidentally, I also have a separate site that was on a TZ that had two local VLANs with a L3 switch behind X0 with two other networks it's v4 NATing configured, but was only ever able to get a /64 PD from Spectrum (legacy TWC), so it ended up going to the LAN interface on the transit network, while the DMZ went unnumbered.  Even trying to "force" a /60 or /56 from within SonicOS only ever produced a /64 delegation, so I turned off v6 entirely, because I can always revisit it later when my Spectrum market "gets it together", and they're also still allocating v4 addresses.

But I have that luxury.  Others may not.  I can't dictate to them what's best for their networks.

[Mitch_Hennessy]

---

@pstewart wrote:

"A lot of the mess is trying to force IPv6 into a NATed IPv4 world of today.  v6 is old (first draft was back in '98), but only just received standardization last year, and there are still issues that IPv6 only networks don't address or have agreed upon solutions for -- many of which probably apply heavily to Meraki networks, like multi-homing and source address selection."

I'm a huge proponent of IPv6 and massively disappointed that Meraki isn't willing to adopt it a few years ago when I strongly feel they should have at a minimum.

Unsure what the "mess" is about though .. I see it deployed at scale in various networks every day.  By deployed, I mean in a dual stack specifically which allows for a transition path fairly easily when the day, in theory, comes to shutdown IPv4.  I'm not a fan of anything other than dual-stack ... all the transition technologies come with a certain degree of pain.

Also, with regards to standardization I'm not sure what you are referring to with regarding last year.  It's been a ratified and adopted standard for many years now - I first started deploying IPv6 into enterprise and service provider networks back in 2008 ... 10 years ago.

Just some two cents on your post ...

Paul

---

I'll start off with a big thanks for the feedback.  Sincerely.  As I said, I'm typing from my own understanding and there are plenty of much smarter folks than me going back and forth on the topic -- maybe even to this day.  I don't know.

IPv6, as far as I've read, became an Internet Standard last year. That's what I meant. And, again, I'm sincerely not trying to start a debate over it; there's enough of it on the 'Net already. Nor am I against IPv6 in the first place. I just think in many walks of life there are those who think IPv6 is a simple drop-in replacement for their existing IPv4 address space and nothing else at all needs to change because everything is NATed and you just go on about your business.

I use the term "is kinda a mess" as a benignly terse way of saying "is not fun to try to pigeonhole as a drop-in replacement for certain types of IPv4 networks" (which I previously specified), but precisely because I think Meraki "SDWAN" networks are the types of networks that might have the most issues with it (or require the most re-engineering), at least from my understanding of it and having read more RFCs than I'd ever thought I would.

Like I said in my super-long first post: IPv6 is no show-stopper for simple, flat, single LAN networks, especially those that use public (ISP, Google, OpenDNS, etc) DNS on the LAN. 999 times out of 1000, users would probably not notice anything change. And that's an absolutely great thing. I certainly think Meraki should at least be able to address those customers. You'll get no argument from me on that one. But I don't work for them (or Cisco), so I can't dictate their product timelines.

Similarly large enterprises are more likely not going to have issues, because they'd be the most likely to a) apply for and receive their own PI prefix allocation from an RIR or LIR sponsor and b) be located (or have data centers located) in markets where ISPs will gladly BGP peer with them to advertise their static allocations. Inside the network the LLAs and PI GUAs won't change so ULA, NAT66, NAT64, NAT46(?) and NPTv6 are then completely unnecessary (which aligns perfectly in the spirit of IPv6's intensions) -- which also means Active Directory won't complain (and server admins will stay happy). Because you're provider independent, you have failover-ability as long as your upstreams agree to peer with you, so you maintain active/standby or active/not-as-active failover functions. They're also more likely to use Merakis in passthrough mode for inline filtering, because their edge devices are gear more likely from the bigger outfits that support BGP path prepending and community strings -- though, I don't know if passthrough MXes can filter or inspect v6 traffic or if it's only transparently passing traffic along. This may already be possible to do as long as the Meraki is only used as an inline passthrough device, right? Someone please feel free to correct me if I have that wrong.

I think those shops in between (which I think a lot of the larger or more nuanced Meraki networks fall under) are the ones who might have any/the most teething pains during the transition, because Meraki MXes have allowed line-blur between what the really "big shops" are doing and what the really small shops are doing with their SDWAN implementation. AutoVPN now allows remote site-to-site connectivity without requiring static assigned public addresses (so, no PI vs PA static/dynamic choice to make) or having to choose to run aggressive mode (and run afoul of auditing depending on which set of complaince rules your business might be subject to). Or those that do active/active uplink source routing at the Meraki to split voice and data or VPN and Internet or performance-class based traffic between each uplink simultaneously. In IPv4, the Meraki makes that decision because it's also doing the translation -- the hosts don't care because they only have an RFC1918 address space to originate non-loopback traffic from so that removes the responsibility of Windows (or macOS or Linux or iOS or Android or, or or or...) having to pick a source address or pick the correct source address. In IPv6 with dual active non PI uplinks comes dual, simultaneous prefixes assiged as GUAs, so now that places the burden of source address selection on the hosts now to select the correct source address. NAT66 and/or NPTv6 could mitigate that and return the upstream routing decisions solely to the Merakis again which returns the "SDWAN"-ness, but then that would almost require using ULA, and with that you're pretty much making ULA exactly like RFC1918 addresses. Should MXes "support" (allow) that? Depends on whom you ask. I can't answer that question for them. There are RFCs for it, but who's to say it won't be superseded in two years?

These are the issues I think Meraki (or larger Meraki networks) are more likely to face in the transition. I don't know how many of Meraki's networks fall under that category (my remote sites certainly do) percentage-wise.  Meraki does, however. Maybe that's why their priorities are the way they are. You'd have to ask them and hope they'd be willing to fully (and transparently) answer that question.

I think at the root of it, a lot of the confusion and even some of the pushback comes from the desire to make the current (and "new" v6) Internet work for them and their network and their gear, rather than the other way around. Some people don't want to hear "no NAT, do dynamic prefixes and move all your on-prem stuff to the Cloud. What are you even doing with AD and an Exchange server on-prem in 2018?" or "suck it up, get a PI prefix allocation and pay your yearly ARIN/RIPE/APNIC fees and find a data center to move your stuff into to do BGP peering".  I also understand that position, especially if they're not forced to change because they DO have a v4 address and the Meraki gear that lets them work around it.  Why would they? They have the luxury of resisting the change.

Maybe this is the conversation we really need to be having with all of our vendors and application stake holders and providers.  Schedule vendor meets and say "what IPv6 options do you have for me in this scenario" or "is there a way to do what I do now with Meraki SDWAN with IPv6 without doing NAT66, NPTv6 or using ULAs?"  Maybe Meraki and other vendors need to meet with ISPs and RIRs and get on the same page (if they're not already), because it would certainly help if all the ISPs (and their various markets) were on the same page about residential vs business class vs multi-site business v6 allocation prefixes.

[ph0t0g]

Mitch,

Thanks for taking the time to lay all that out for us. I too was on the Bash Meraki Bandwagon until I read you two posts. I don't pretend to understand all of it, but I got enough to realize there is a lot to consider when starting to look at IPv6. We as consumers and they as vendors have a lot of difficulties to overcome and not much time to do it. It seems we don't have much choice but to educate ourselves as quickly as possible (as it seems like you are doing). IPv6 is the only way forward, so we might as well start taking our lumps now.

I am still undecided whether to keep my Meraki equipment, or try to find another vendor who's SMB products are further along with IPv6 (if such a vendor exists - suggestions welcome). Three to six months before a timeline is available? Ooofa! That's very concerning.

[cmw]

Hi Mitch,

Thanks for taking the time to offer your insight on the topic.  I completely agree that IPv6 is not a drop-in replacement for IPv4 and I also agree that many of the detailed aspects of IPv6 bring complexity into the networking world as many of us have long known it.

I have long asserted that much of this is not a shortcoming of IPv6 but an insistence by people trying to overlay old ideas (ahem, workarounds) into their IPv6 deployments (RFC 1918 IPs and NAT at the top of that list).  IPv6 is the so-called round peg and people insist on banging it into square hole that is IPv4.  It doesn't fit and forcing it is going to go poorly.  Any mention of NAT66 makes the hair on the back of my neck stand up because it exactly illustrates the 'gotta have NAT mentality' that an entire generation was born into and don't want to let go.  It's all they've ever known and a world without NAT44 or NAT66 is beyond comprehension.  Yes, yes, we can quickly get into discussions like provider independent address space and what that means to a network move but the railing I have heard over that across the years is mostly hyperbole to a healthy portion of us.

None of these challenges have kept a multitude of other vendors from offering v6 in their products and if Meraki was thinking of holding off on v6 until it was somehow better baked... dang.  We're 22 years in to v6 now; improvements are full on in the incremental stage.  Better baked isn't coming.  This is it. 

To start, here's what I would like to see from Meraki:

- The ability to assign an IPv6 address to my Internet interface(s) (along with a corresponding default route).

- The ability to specify v6 Internet DNS servers

- The ability to manually assign a /64 prefix to my VLAN interfaces and VPN network which I will derive from the /48 or /56 or /60 assigned by my provider (no DHCP-PD needed).  This would include the ability for me to specify, if nothing else, DNS info to be included in my router advertisements.

- Firewall rules on par with the existing v4 functionality. 

- The ability to create a 6over4 GRE tunnel (for people who still need to tunnel through their providers v4-only network).

Longer term:

- DHCP Prefix Delegation would be nice because it would help a lot of Meraki customers.

- Internal DHCPv6 is also a nice to have (including reservations); in many cases we can get along just fine without it.

- Client VPNs with IPv6

I'm curious to know what other features people would consider 'essential' for their v6 deployments.  Please tell.

Thanks.

cmw

[JPAWELCHAK]

Meraki Team,

Are you hearing any of this? Comments and updates please, acknowledging comments and keeping the community updated on this stuff is not rocket science.

Again, why are we 3 to 6 months out from a roadmap still? None of this makes sense considering IPv6 specifications have been out for so long.

[Bovie2K]

@Daghan Thanks for the update. Please pass to management the need for an active road map for MX like IPv6, IKEv2, Anyconnect support, network objects and groups (Love that you mentioned this one) and finally
Site-to-site inbound firewall (which even shows up on the dashboard). Eagerly awaiting all these features.

[ph0t0g]

@Daghan post made me feel a little better. @Mitch_Hennessy posts made me apprehensive. However, I re-upped my Meraki licenses for another year.

C'mon Meraki, don't make me look stupid.

-P

[JPAWELCHAK]

---

@Daghan wrote:

I run part of Meraki Product Management that includes MX.

We agree (PM / Eng teams) with everyone on this list that we need IPv6 and we need it yesterday! 

There is nothing sinister about the delay. It isn't a hardware limitation, nor a Cisco ploy to drive a wedge between Meraki and Enterprise Networking products. In fact, we have engineers working on IPv6 right now and we are in the process of formulating an accurate roadmap. I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when. 

What is taking us this long?

When I launched MX with 2 engineers 8 years ago, we were the little engine that could. One strategy we adopted was to "fit the use-case", not to build generic features. Well, in some instances, we overfitted some of those use-cases that created technical debt. We had no clue that we had to worry about it. If someone came to me in 2011 and said you'll sell 1M MX in the next 8 years, I would have asked which psychedelic drug there were on.

But it happened!  We are energetically trying to redo some of our earlier decisions (network objects, n uplinks, no-nat, full support for BGP...are some highlights from our infinitely long to-do list).

None of the above is an excuse, but I wanted to shine the light of transparency on our thought process. 

To remain a strong (we are in fact 14K customers strong) SD-WAN provider, we have to put IPv6 behind us... and we will.

Thanks,

Daghan.

---

@Daghan @tnight Update please, you promised timely updates yet there have been none. Again, none of this IPV6 stuff should come as a surprise to Meraki, therefore, why isn't Meraki with the resources of Cisco behind them further along than this? If at this point you still don't have a roadmap someone quite simply isn't doing their job. Meraki is a premium product not keeping pace with vendors at a fraction of the cost on the IPV6 front.

[smccloud]

---

@JPAWELCHAK wrote:

---

@Daghan wrote:

I run part of Meraki Product Management that includes MX.

We agree (PM / Eng teams) with everyone on this list that we need IPv6 and we need it yesterday! 

There is nothing sinister about the delay. It isn't a hardware limitation, nor a Cisco ploy to drive a wedge between Meraki and Enterprise Networking products. In fact, we have engineers working on IPv6 right now and we are in the process of formulating an accurate roadmap. I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when. 

What is taking us this long?

When I launched MX with 2 engineers 8 years ago, we were the little engine that could. One strategy we adopted was to "fit the use-case", not to build generic features. Well, in some instances, we overfitted some of those use-cases that created technical debt. We had no clue that we had to worry about it. If someone came to me in 2011 and said you'll sell 1M MX in the next 8 years, I would have asked which psychedelic drug there were on.

But it happened!  We are energetically trying to redo some of our earlier decisions (network objects, n uplinks, no-nat, full support for BGP...are some highlights from our infinitely long to-do list).

None of the above is an excuse, but I wanted to shine the light of transparency on our thought process. 

To remain a strong (we are in fact 14K customers strong) SD-WAN provider, we have to put IPv6 behind us... and we will.

Thanks,

Daghan.

---

@Daghan @tnight Update please, you promised timely updates yet there have been none. Again, none of this IPV6 stuff should come as a surprise to Meraki, therefore, why isn't Meraki with the resources of Cisco behind them further along than this? If at this point you still don't have a roadmap someone quite simply isn't doing their job. Meraki is a premium product not keeping pace with vendors at a fraction of the cost on the IPV6 front.

---

I am really regretting the suggestion to go with Meraki at work at this point.  At least at home I can easily swap out for Ubiquiti or something else but not so much at work 😞

[danielpugh]

our backup (mobile broadband provider - EE/uk) _only_ support ipv6

so we have no backup broadband despite having a supported usb stick (and in fact a huawei broadband router that supports ipv6)

Really annoying!

(especially when combined with the lack of ikev2 so we can vpn reliably to azure!)

[ScubaSteve]

Oh but don't worry.... they are focused on putting things like WAN health which should be a part of the native license into Meraki Insight. What the heck is going on Meraki! 

Honestly, I cannot fight for you guys anymore. We have really sucky reporting features. Sure I can see an overview but I can't choose between date and times. No IPv6 capabilities. All of Meraki Insight which shouldn't be a separate nickel and dime package, Poor log keeping (Why can't we save these logs, reports etc on the internal drives with the ones that have them?). No native Meraki VPN Client, No ikev2, the password on the VPN is unencrypted. My gosh. Even the firmware updates are dismal. In order to use anything useful they force you on the Betas.

It just frustrates me after spending 30k + that this is what we get. Don't get me wrong.. the idea behind it is awesome. I see the potential. But its so hard to sit back and watch it take the wrong directions all the freaking time.

I am starting to think Meraki needs some serious restructuring done. This is not the way to run a company that touts itself as enterprise ready.

[JPAWELCHAK]

@ScubaSteve wrote:

Oh but don't worry.... they are focused on putting things like WAN health which should be a part of the native license into Meraki Insight. What the heck is going on Meraki! 

Honestly, I cannot fight for you guys anymore. We have really sucky reporting features. Sure I can see an overview but I can't choose between date and times. No IPv6 capabilities. All of Meraki Insight which shouldn't be a separate nickel and dime package, Poor log keeping (Why can't we save these logs, reports etc on the internal drives with the ones that have them?). No native Meraki VPN Client, No ikev2, the password on the VPN is unencrypted. My gosh. Even the firmware updates are dismal. In order to use anything useful they force you on the Betas.

It just frustrates me after spending 30k + that this is what we get. Don't get me wrong.. the idea behind it is awesome. I see the potential. But its so hard to sit back and watch it take the wrong directions all the freaking time.

I am starting to think Meraki needs some serious restructuring done. This is not the way to run a company that touts itself as enterprise ready.

@ScubaSteve the man you want to say this to is @tnight, he's the guy at the top of the Meraki org. chart. @Daghan is on the MX team that commited to regular updates but none provided since popping up his head. I completely agree the Insight functionality SHOULD be part of the MX Enterprise License or MX Advanced Security License at minimum if they are looking for incremental revenue on the product and should not be a nickle and dime add-on as you say. At this point I'm not sure why Meraki even has this community when all they are willing to comment on is the light and fluffy stuff but not post anything in the way of value re IPv6 and when they do comment its with lip service and non-answers for the most part. I just don't get how according to @Daghan in his one and only response they were 3 to 6 months from having a road map 3 months ago, is that his way of saying they hadn't started on a road map yet for a standard that has long been ratified and actively being deployed in the wild by vendors (Meraki excluded of course)?

[pstewart]

The only way Cisco and Meraki will take note of this is by "voting with your wallet" I'm sorry to say.  I'm just in the process of ripping out a lab system that was purchased with the intent of purchasing a large amount of Meraki.  Since then I've changed our plans for rollout from Meraki to another system (doesn't matter who as that's not the point).

I had this exact conversation about 4 months ago with a very large Meraki customer and they are frustrated.  They have talked to their sales rep along with a regional manager and were re-assured IPv6 is a priority.  Much the same as my conversation, the question came up as to why this is even a question in 2018 ... much shock set in when myself and this other company realized that development might take a couple of years before Meraki releases anything.  If that's not true then that would mean development is well underway and more could be shared but what I understand is another few months from now just to get a timeline and resources scheduled to *begin* looking at this.  

Well, to be blunt .. it's at least a FEW years too late.  One could even argue it's 10 years too late as that's how long I've been deploying IPv6 into service provider and enterprise networks.

The large customer I referenced is going to start converting 10,000 units at a time ... the sad thing that I know will happen is that nobody will notice until *after* that customer has migrated away as that's exactly what will happen for me.

[ScubaSteve]

I whole heartedly agree. The money always talks. I just wish I had enough units out there where I could push that. At this rate I am sure a lot of companies will start switching out. I am starting to see on a lot of forums including spice works to stay clear of Meraki. Sad.

[smccloud]

I have made the decision that at home I will be swapping out my entire Meraki stack (MX64, MS220-8P & MR33) for a Netgate SG-1100, my old Dell PowerConnect 2724 (for now) and a UniFi UAP-AC-Pro or nanoHD with an upgrade to a UniFi switch with PoE at some point in the future.  All because we still have no news on IPv6 being implemented but lots of other "fluff".  Granted, I'm not replacing my office gear, but when our license requires renewal who knows.

[DHAnderson]

Before getting my MX65, I was using Sonicwall TZ300.  I have Charter service and my TZ300 was getting a /62 subnet from them.  The TZ300 used Router Advertisement which passed through my MS220-8P and MR33 without any problem, so both wired and wireless clients were able to get IPV6 address. The MS220-8P and MR33 also received IPV6 addresses.

In short, you have an IPV6 network by replacing your MX64 with something roughly equivalent, like a TZ300.

[danielpugh]

at home i have usg-pro4 (and uap ac pro aps) all working great for a couple of years...

i like meraki - just amazed that it is missing some key features

gonna have to be patient and int the meantime using suitable alternatives e.g. cisco routers & ASA

[BizCat]

So it has been 1 year, 6 months, 15 days since this thread was first made and we are still waiting for IPV6 for the MX.

This is pathetic, we need this now more than ever due to EE handing out IPV6 on iOS meaning our workforce can no longer connect to our network via VPN.

What would be cheaper, replace the MX or our fleet of iPhones..... I am guessing replace the MX which I will do very soon.

[TheOldGuy]

We pulled all of our MX’s from clients out a bit over a year ago and within six months will be totally Meraki free. We are trying to use nothing Cisco over just this. We have a need do four of the Nexus 7700’s and have put that off almost 9 months due to this. They need to fix this ASAP!

[TheOldGuy]

We pulled all clients off of MX a bit over a year ago and we will have Meraki completely out within 90 days. I can’t wait! We are waiting to order and deploy 4 Nexus 7700s due to this at a larger client and are currently actively recommending against Cisco in any way just due to this.

[nikiwaibel]

as you can see here (Switch / ACL)

IPv6 support can be implemented - in some cases - extremely simple (at least in the UI). if IPv4 is chosen, source and destination are validated in the traditional way; otherwise (IPv6) some different validation rules apply.

this should/could/must go into Security & SD-WAN / Configure Firewall and Wireless / Configure / Firewall & traffic shaping / Block IPs and ports as well.

[DHAnderson]

Unfortunately, it sounds like the issue is the design of the MX that is the complicating factor. 

The good news is that in the April Quarterly, they did not directly answer a question about IPV6, but they did say that they are working on it.

[DHAnderson]

Unfortunately, it sounds like the issue is the design of the MX that is the complicating factor. 

The good news is that in the April Quarterly, they did not directly answer a question about IPV6, but they did say that they are working on it.

[JasonCampbell]

Unfortunately, that is NOT good news, that is the same non-news we as Meraki partners have had for the past 2 years. Same thing as with a proper Sslvpn client (Anyconnect integration)

Please do not try to sugar coat this for Meraki. The fact is they are failing to keep up with industry standards and no one, especially clients, should be making excuses for their failure to deliver an enterprise firewall solution. 

[JPAWELCHAK]

---

@DHAnderson wrote:

Unfortunately, it sounds like the issue is the design of the MX that is the complicating factor. 

The good news is that in the April Quarterly, they did not directly answer a question about IPV6, but they did say that they are working on it.

---

@DHAnderson That is certainly nothing new! It's the same statement Meraki have made during the last umpteen Quarterly's. Meraki's senior management acknowledge they have done a poor job communicating to the community about IPv6 yet do nothing to resolve it.  @Daghan promised a roadmap months ago yet nothing, just more of the same silence.

[DHAnderson]

I agree that communication has been poor on this issue.

There have been statements that early decisions were made about the MX design that need to be rethought because of IPV6.  Besides the technical issues related directly to an IPV6 stack, there likely is the issue of a schema design change in the MX.  This would mean potential complex transition steps from old MX to IPV6 MX.  One would want to preserve any IPV4 settings on an existing production MX after such an upgrade for IPV6, and that schema change requires careful planning and execution on Meraki's part.

[Uberseehandel]

• 1996 - IPv6 specified (RFC 1883)
• 2006 - Meraki founded

No excuse for any engineer at Meraki to be blind-sided by IPv6. 

Trying to explain away the reality that the engineers really screwed up just insults the audience being addressed.

Can we have some straight talk please from somebody at the C-level. Vague flummery or testiculation will only exacerbate an already bad situation.

Note for the philologists: testiculation - waving one's arms around whilst talking balls.

[nikiwaibel]

A customer asked his internet provider to setup a cost-free, public IP address (as of EU-VO2015/2120 Art3 Abs1/2).

Answer: You'll get an IPv6 net for free, but an IPv4 address only for $$. That's already clarified with the Austrian regulatory authority (RTR).

Meraki: ACT!

The actual email follows (German):

---

Betreff:	[XXX #NNN] Bitte um Öffentliche IP Adresse
Datum:	Tue, 21 May 2019 09:16:44 +0200
Von:	AAA BBB via RT <CCC@XXX.at>

Sehr geehrter DDD,

allen unseren Kunden wird ein öffentliches IPv6-Netz zugewiesen. Die
öffentliche IP-Adresse muss nicht IPv4 sein, so steht es in den BEREC
Leitlinien zur Netzneutralität und ist auch mit der RTR (Rundfunk und Telekom
Regulierung) so abgeklärt. Auf Grund der Knappheit von IPv4 Adressen könnten
viele - insbesondere noch nicht so lange am Markt befindliche - Anbieter sonst
keine Internetzugangsleistungen anbieten.

Wir weisen bei der Bestellung sowie in der Leistungsbeschreibung ausdrücklich
darauf hin, dass es sich bei den Privat-Produkten von CCC um IPv6 sowie im
IPv4 Bereich Carrier-NAT handelt und auf Wunsch eine statische öffentliche IPv4
Adresse um 2,40 Euro dazugebucht werden kann:
...Die Anbindung des Anschlusses an das Internet erfolgt über ein öffentliches
IPv6-Netz sowie über eine betreiberinterne IPv4-Adresse (Carrier-Grade-Nat –
CGN)....

Es gibt kostenfreie und kommerzielle Dienste, die einzelne Ports von IPv4 auf
IPv6 (IPv4 zu IPv6 Port Mapping) weiterleiten. Zwei Beispiele:
Freier Dienst: https://myonlineportal.net/portmapper
Kommerzieller Dienst:
http://www.feste-ip.net/dslite-ipv6-portmapper/allgemeine-informationen/

Alternativ bieten wir die statische öffentliche IPv4 Adresse um 2,40 Euromonatlich an.

Mit freundlichen Grüßen, EEE

[danielpugh]

if only i had the luxury of being able to pay

EE in the UK said its simply not an option any more.

raising the spectre of what to do with a publicised feature (4g wan backup) not working the 4g providers all work with ipv6 only...

[nikiwaibel]

this is a bug, not a missing feature. i think that's unclear to them.

[danielpugh]

i think the line is that the feature of ipv6 wan has never been advertised, and so it is not possible for it to be filed as a bug.

however the lack of support results in another feature (4g failover) not working 

which maybe then is classed as a bug (grey area)?

[Uberseehandel]

---

@danielpugh wrote:

if only i had the luxury of being able to pay

EE in the UK said its simply not an option any more.

raising the spectre of what to do with a publicised feature (4g wan backup) not working the 4g providers all work with ipv6 only...

---

Curiously, yesterday I activated an EE LTE/4G data SIM, which was assigned an IPv4 address on activation. Whether it will always be the same IP address, I do not know, but as it is for a travelling Z3C, the cellular sub-system will be enabled/disabled frequently, so I shall soon find out. I did not have to specify IPv4.

It occurs to me that the person who declined your request for an IPv4 address, did not understand the implications as far as you are concerned, and that such a request should be fulfilled if at all possible. Perhaps you could move up the food chain at EE and find somebody who can make things happen.

[danielpugh]

tried and tried with support, but despite multiple support people they werent able to help, and refunded me.

i suspect its some level of automation that gives out ipv4 automatically based on the device (we have a cisco ISR with 4g card that got an ipv4 when installed last week), but it didnt work on ours...

as a second level - what i ideally want (but will probably never get) is;

4g router (decent mimo aerials and upgradeable) -> lan port -> meraki (mx64) wan2

tried that, but although a pc works fine via ipv6, obviously the meraki didnt

[ScubaSteve]

Thanks for your response @JPAWELCHAK. I have had the opportunity to work for very large companies. I can guarantee you that was stated by Meraki was a simple PR Stunt / Crowd Control to buy them time. They know they made a mistake. When they say road map what they mean is they planned on implementing IPv6 eventually but haven't looked at it yet.

The thing I hate most is lip service and no action. I can understand if the company said... we made a mistake, we apologize, we didn't even plan on it. Here is where it is at on the road map, we plan on having X, Y, Z ready for testing by X date. And if they don't hit that date.. thats fine.. but tell us... say something as simple as we ran into a few snags but we are close or not close. I don't care. Transparency brings trust into a company. With trust comes sales.

We have this year to watch what happens. If nothing substantial happens we really don't have a choice but to drop Meraki and go with another provider (Eyeballing Palo Alto). We can't play this game with a company we don't trust with our production environment. 

Lastly I forgot to mention the tech support has gone way down hill. In the good ole days before Cisco took over we had an actual engineer look at our issues and got them resolved fairly quickly. Now, we take a million packet captures that they don't know how to interpret and don't seem to understand the issue. I also just love the fact that they can see a lot more than I can on my own equipment. (insert sarcasm here). 

Please Meraki.... don't let me down. I want this to work so bad.

[JPAWELCHAK]

---

@Daghan wrote:

I run part of Meraki Product Management that includes MX.

We agree (PM / Eng teams) with everyone on this list that we need IPv6 and we need it yesterday! 

There is nothing sinister about the delay. It isn't a hardware limitation, nor a Cisco ploy to drive a wedge between Meraki and Enterprise Networking products. In fact, we have engineers working on IPv6 right now and we are in the process of formulating an accurate roadmap. I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when. 

What is taking us this long?

When I launched MX with 2 engineers 8 years ago, we were the little engine that could. One strategy we adopted was to "fit the use-case", not to build generic features. Well, in some instances, we overfitted some of those use-cases that created technical debt. We had no clue that we had to worry about it. If someone came to me in 2011 and said you'll sell 1M MX in the next 8 years, I would have asked which psychedelic drug there were on.

But it happened!  We are energetically trying to redo some of our earlier decisions (network objects, n uplinks, no-nat, full support for BGP...are some highlights from our infinitely long to-do list).

None of the above is an excuse, but I wanted to shine the light of transparency on our thought process. 

To remain a strong (we are in fact 14K customers strong) SD-WAN provider, we have to put IPv6 behind us... and we will.

Thanks,

Daghan.

---

@Daghan @tnight 

In Nov. of 2018 you said and I quote "I believe we are within 3-6 months window for being able to articulate what IPv6 features will be available when." yet a full 10 months later Meraki continues to remain silent and frustrate an ever growing number of us. It's one thing that that Meraki is handling this IPv6 thing poorly in the first place but then to completely ignore their commitment to do better and articulate their plan is simply unacceptable.

[Dudleydogg]

This Reply was 2 Years ago and no closer to IPV6, Many of us still use Meraki Networks but have Alternate Options for Routers. My Entier Network is Meraki but I put MX on the shelf and using another Vender for Router.

WE Hope this year we can go Pure Meraki Some of us are even willing to take whatever Beta is out there.

[DHAnderson]

@Dudleydogg 

The has been forward movement on IPV6.  Making the Dashboard IPV6 compatible is a necessary precursor.

I get it that the MX still has no alpha or beta yet and that leaves those who require IPV6 still stuck.

[DHAnderson]

Is Edgar Allan POE lost love Lenore in the following poem, our MX IPV6 support?  Or is this just the ramblings of a Covid19 feverish mind?

The Raven

BY EDGAR ALLAN POE

Once upon a midnight dreary, while I pondered, weak and weary,

Over many a quaint and curious volume of forgotten lore—

    While I nodded, nearly napping, suddenly there came a tapping,

As of some one gently rapping, rapping at my chamber door.

“’Tis some visitor,” I muttered, “tapping at my chamber door—

            Only this and nothing more.”

    Ah, distinctly I remember it was in the bleak December;

And each separate dying ember wrought its ghost upon the floor.

    Eagerly I wished the morrow;—vainly I had sought to borrow

    From my books surcease of sorrow—sorrow for the lost Lenore—

For the rare and radiant maiden whom the angels name Lenore—

            Nameless here for evermore.

    And the silken, sad, uncertain rustling of each purple curtain

Thrilled me—filled me with fantastic terrors never felt before;

    So that now, to still the beating of my heart, I stood repeating

    “’Tis some visitor entreating entrance at my chamber door—

Some late visitor entreating entrance at my chamber door;—

            This it is and nothing more.”

    Presently my soul grew stronger; hesitating then no longer,

“Sir,” said I, “or Madam, truly your forgiveness I implore;

    But the fact is I was napping, and so gently you came rapping,

    And so faintly you came tapping, tapping at my chamber door,

That I scarce was sure I heard you”—here I opened wide the door;—

            Darkness there and nothing more.

    Deep into that darkness peering, long I stood there wondering, fearing,

Doubting, dreaming dreams no mortal ever dared to dream before;

    But the silence was unbroken, and the stillness gave no token,

    And the only word there spoken was the whispered word, “Lenore?”

This I whispered, and an echo murmured back the word, “Lenore!”—

            Merely this and nothing more.

    Back into the chamber turning, all my soul within me burning,

Soon again I heard a tapping somewhat louder than before.

    “Surely,” said I, “surely that is something at my window lattice;

      Let me see, then, what thereat is, and this mystery explore—

Let my heart be still a moment and this mystery explore;—

            ’Tis the wind and nothing more!”

    Open here I flung the shutter, when, with many a flirt and flutter,

In there stepped a stately Raven of the saintly days of yore;

    Not the least obeisance made he; not a minute stopped or stayed he;

    But, with mien of lord or lady, perched above my chamber door—

Perched upon a bust of Pallas just above my chamber door—

            Perched, and sat, and nothing more.

Then this ebony bird beguiling my sad fancy into smiling,

By the grave and stern decorum of the countenance it wore,

“Though thy crest be shorn and shaven, thou,” I said, “art sure no craven,

Ghastly grim and ancient Raven wandering from the Nightly shore—

Tell me what thy lordly name is on the Night’s Plutonian shore!”

            Quoth the Raven “Nevermore.”

    Much I marvelled this ungainly fowl to hear discourse so plainly,

Though its answer little meaning—little relevancy bore;

    For we cannot help agreeing that no living human being

    Ever yet was blessed with seeing bird above his chamber door—

Bird or beast upon the sculptured bust above his chamber door,

            With such name as “Nevermore.”

    But the Raven, sitting lonely on the placid bust, spoke only

That one word, as if his soul in that one word he did outpour.

    Nothing farther then he uttered—not a feather then he fluttered—

    Till I scarcely more than muttered “Other friends have flown before—

On the morrow he will leave me, as my Hopes have flown before.”

            Then the bird said “Nevermore.”

    Startled at the stillness broken by reply so aptly spoken,

“Doubtless,” said I, “what it utters is its only stock and store

    Caught from some unhappy master whom unmerciful Disaster

    Followed fast and followed faster till his songs one burden bore—

Till the dirges of his Hope that melancholy burden bore

            Of ‘Never—nevermore’.”

    But the Raven still beguiling all my fancy into smiling,

Straight I wheeled a cushioned seat in front of bird, and bust and door;

    Then, upon the velvet sinking, I betook myself to linking

    Fancy unto fancy, thinking what this ominous bird of yore—

What this grim, ungainly, ghastly, gaunt, and ominous bird of yore

            Meant in croaking “Nevermore.”

    This I sat engaged in guessing, but no syllable expressing

To the fowl whose fiery eyes now burned into my bosom’s core;

    This and more I sat divining, with my head at ease reclining

    On the cushion’s velvet lining that the lamp-light gloated o’er,

But whose velvet-violet lining with the lamp-light gloating o’er,

            She shall press, ah, nevermore!

    Then, methought, the air grew denser, perfumed from an unseen censer

Swung by Seraphim whose foot-falls tinkled on the tufted floor.

    “Wretch,” I cried, “thy God hath lent thee—by these angels he hath sent thee

    Respite—respite and nepenthe from thy memories of Lenore;

Quaff, oh quaff this kind nepenthe and forget this lost Lenore!”

            Quoth the Raven “Nevermore.”

    “Prophet!” said I, “thing of evil!—prophet still, if bird or devil!—

Whether Tempter sent, or whether tempest tossed thee here ashore,

    Desolate yet all undaunted, on this desert land enchanted—

    On this home by Horror haunted—tell me truly, I implore—

Is there—is there balm in Gilead?—tell me—tell me, I implore!”

            Quoth the Raven “Nevermore.”

    “Prophet!” said I, “thing of evil!—prophet still, if bird or devil!

By that Heaven that bends above us—by that God we both adore—

    Tell this soul with sorrow laden if, within the distant Aidenn,

    It shall clasp a sainted maiden whom the angels name Lenore—

Clasp a rare and radiant maiden whom the angels name Lenore.”

            Quoth the Raven “Nevermore.”

    “Be that word our sign of parting, bird or fiend!” I shrieked, upstarting—

“Get thee back into the tempest and the Night’s Plutonian shore!

    Leave no black plume as a token of that lie thy soul hath spoken!

    Leave my loneliness unbroken!—quit the bust above my door!

Take thy beak from out my heart, and take thy form from off my door!”

            Quoth the Raven “Nevermore.”

    And the Raven, never flitting, still is sitting, still is sitting

On the pallid bust of Pallas just above my chamber door;

    And his eyes have all the seeming of a demon’s that is dreaming,

    And the lamp-light o’er him streaming throws his shadow on the floor;

And my soul from out that shadow that lies floating on the floor

            Shall be lifted—nevermore!

[Uberseehandel]

Proctor & Gamble have the solution you seek - https://www.lenor.co.uk/en-gb 

[DHAnderson]

There is a hint of a change coming to the MX line.  Version 15.38 mentions "a new major version evolving through beta...".  Perhaps IPV6 or at least the underpinnings of it are close!

-Dave 

[nikiwaibel]

well, that's there since 15.23:

As a new major version evolving through beta, there are a number of new, uncommon issues that may result in device reboot that we are continuing to investigate and work through. In particular, the Z3(C), MX84, MX100, MX400, MX600, MX250, and MX450 appliances have unresolved issues that we are tracking closely and continuing to investigate and drive towards resolution.

i doubt it is related to IPv6.

[DHAnderson]

The Meraki line of hardware will have to support both IPV4 and IPV6 stacks.  Perhaps the MX beta is for a more modular stack based implementation of the current IPV4 code.

- Dave

[cmw]

Man, I'm feeling pretty silly right now.  I have supported v4-only client networks with Meraki gear and thought so highly of it that I ordered one for my office.  It arrived this afternoon, I plugged it in, got to setting up and then couldn't find the v6 config options.  I thought I was just missing them somehow.  And then I found my way here.  And now I'm sad.

It's very much my own fault for making an assumption.  I sheepishly admit that.  I assumed that something I consider fundamental (IPv6 support) to a piece of networking gear like this (MX68W) was just a given. So much so I didn't double check.  I'm a little blown away over it.  I checked my calendar.  Yup, 2018.  It's not 2005.

I think the Meraki product line is awesome and I was so excited to have it in my own network but this is a deal-breaker for me.  I'm really not happy about it but this will have to go back in the box and sent away.

Seriously bummed...

cmw

[JPAWELCHAK]

---

@cmw wrote:

Man, I'm feeling pretty silly right now.  I have supported v4-only client networks with Meraki gear and thought so highly of it that I ordered one for my office.  It arrived this afternoon, I plugged it in, got to setting up and then couldn't find the v6 config options.  I thought I was just missing them somehow.  And then I found my way here.  And now I'm sad.

It's very much my own fault for making an assumption.  I sheepishly admit that.  I assumed that something I consider fundamental (IPv6 support) to a piece of networking gear like this (MX68W) was just a given. So much so I didn't double check.  I'm a little blown away over it.  I checked my calendar.  Yup, 2018.  It's not 2005.

I think the Meraki product line is awesome and I was so excited to have it in my own network but this is a deal-breaker for me.  I'm really not happy about it but this will have to go back in the box and sent away.

Seriously bummed...

cmw

---

@cmw RMA the hardware and licences, you have 30 days to do so.

[cmw]

Thanks @JPAWELCHAK, I have already been in touch with my sales rep.  They are very helpful.

I have built a workaround that works and am in the process of deciding if it's worth it/secure enough, etc. 

Aside from the IPv6 thing I really like Meraki so I'm using the next several days to see if I can make things work.

cmw

[CptnCrnch]

This post is almost two years old and still nothing has happened? I‘m working for one of Europes‘ biggest Cisco partners and thinking about upcoming SD-WAN projects, this could be a showstopper for Meraki equipment 😞

[V1Rotate]

Agreed. It would be nice for an update and a roadmap as to Cisco's plan to deploy IPv6 to the Meraki line. We spend good money on our licenses. We don't deserve second rate support to mainline Cisco or lack of answers.

[XROW]

Cisco's position and this thread is rediculous. Look at the time that has passed. The will be never ipv6 in Meraki. Otherwise it would been on the roadmap a long this ago and just completed.

As a partner, I need to replace my Merki now, because I can`t communicate properly with ipv6. What other vendor / product do you recommend?

If cisco would be working on it they would be able to show a prototype. They don`t.... So they havn´t started. How long to you want to wait for a feature that is to big for they to handle or they can`t because of the existing hardware that is not compatible? Switch....

[Mitch_Hennessy]

As I said in my first (or second) post: If you really need v6 WAN, then the MX isn't for you. Especially if you need it right-this-second, change your WAN device to something else that does support your needs.

All other vendors can easily and swiftly include support for it because while they may offer a "cloud" controller option (like Ubiquiti), you still have local access to all other functions of the device from the device itself (or, at least, provides a local controller option as well).

If your network has "stacked" or "cascaded routers" -- like let's say you have a "transit VLAN" in between your WAN and your internal networks, where your DHCP-PD requesting device isn't also then another DHCPv6 server capable of re-delegating delegated prefixes it received from its own upstream delegation, you'll have a difficult time getting your network online to get to the Meraki Dashboard to even set up the network to begin with. I think that's the problem. If Meraki allowed local device access to the same core functions (interface addressing, DHCP, group policies, ARP tables, routing, etc) from the dashboard on the local device itself, this wouldn't be as big of a fundamental mountain to overcome. Especially in a dual-stacked environment.

Since some RFC (I think 6724, which obseleted 3484, I also think) specifies how clients select source addressing with a dual-stacked system, you run the risk of clients in specific network configurations (like the one above) getting degraded performance while it tries to use v6 before falling back to v4.

And that's also ignoring dual/multi-homed WANs without BGP or PI/static PA from statically-assigned prefixes.  That's still a "work-in-progress", too.  Stay single-homed to a single ISP and remove the USB LTE connection, or cancel service on that SIM.  That way you only have a single source address to source v6 traffic from, and if the FW is the only L3 device in your network, SLAAC should work fine unless you're running a domain on your local network.  Or, if the device you switch to has the option of suppressing RAs of the 2nd WAN option as long as your primary WAN is still active, then RAs can fail over your WANs for you in the event of a WAN failure.  Depending on the settings, the failover might not even be noticable unless you're on an active VoIP call.

Maybe everyone clamoring for it here wouldn't have that issue; as long as your FW is the only L3 device in each of your networks, you'll be alright. In which case, as I said here and before: Meraki MX ain't for you. Switch.  That is probably going to be the fastest way to resolve your WAN connectivity issues.

[danielpugh]

Can't say it's possible to go back in time and not buy our mx84.  

For both ubiquity and meraki Mx the device wan is configured locally in order for the device to connect to cloud and obtain configuration, so don't really understand your point.

Currently can't use failover/4g/ipv6 on wan and would like to whilst also believing that at the price point and for many scenarios (customer requirements/business case) this would be important to have.  

At the price point if business grade features are not provided (but are by all other competitors) then meraki sales lose out. As do  Engineers who struggle to install or use and users or customers who are equally unable to understand the (lack of)  explanation...

[Mitch_Hennessy]

I know you can't go back in time and stop yourself from buying your MX84.  I can't go back in time either.

But as far as decisions to be made, you entirely have control over where you go from here:  stay with Meraki MXes and see if "name and shaming" them will get them to move or work any faster to make their devices suit your specific needs...

...or switch vendors.

The situation we're in with Meraki is not just of our own making, but the decision of what to do about it going forward certainly is.  It may not entirely be up to you specifically, but your decision makers certainly have that choice.

As far as Ubiquiti versus Meraki, at least with Ubiquiti you have the option of configuring your entire network from your on-prem controller, irrespective of your WAN or connection to a cloud Dashboard hosted on AWS, or, failing that, you can SSH directly into your USG or EdgeRouter to configure the features you need to work with what you have available.

[danielpugh]

Yep I have one at home (USG pro4)- lacking in the the  but more complex features (my local config file has a lot of settings),I but like mine a lot.

That said i really like the meraki Mx and would really like it to have ipv6 working as it needs to be managed by me or the other engineers who don't know Linux so well (features not in ubiquity controller)

Fingers crossed...

[Uberseehandel]

---

@danielpugh wrote:

Yep I have one at home (USG pro4)- lacking in the the  but more complex features (my local config file has a lot of settings),I but like mine a lot.

 . . . . as it needs to be managed by me or the other engineers who don't know Linux so well (features not in ubiquity controller)

---

Configuration (of the USG) is through the CLI, if it cannot be done through the controller. The  device runs under EdgeOS, which is a fork of Vyatta.

With the right tools (eg decent SSH client and something to browse directories and their contents via a GUI, such as FileZilla), the need for Linux skills is virtually gone. Most of the time SUDO is your friend, if you have rights issues. I think I have one page of notes that cover my required Linux knowledge.

That said, the Meraki dashboard is a more solid piece of software than the UniFi controller, but it can't do as much.

[danielpugh]

Yes you can log on via SSH, but for config that is not supported on the controller you add to the local conf file (e.g. using vi).  This is then merged with the config received from the cloud controller.  

Pretty conversant with the details as we manage hundreds of sites from centralised cloud controllers in aws.   have had the pro4 at home for about 4 years - in those days lots of features were not available on the controller (many are still not such as split DNS).

You are right in that different tools/boxes for different scenarios, but at the same time sticking to the key point of this forum is important as Meraki has many great qualities - key point being that this feature request and a few others (better nat management) are well overdue.

[Uberseehandel]

yes, daniel.

---

[Meraki-PM-Team · Accepted solution]

Hi all, thank you for your continued patience on this topic. We’d like to provide an update and bring further transparency on the IPv6 status for Cisco Meraki products.  Firstly, we want to acknowledge the clear gap in supporting IPv6 across the Meraki portfolio and sincerely understand the frustration that’s been expressed. 

Each Cisco Meraki product has a different set of IPv6 requirements and technical complexities. IPv6 is not a single feature but rather a suite of features and capabilities that need to be enabled as a journey; which, unfortunately, is not a quick undertaking especially since we need to solve for effective management of IPv6 functionality in addition to enabling IPv6 data plane capabilities. 

On our IPv6 journey, we have identified the key functions to be delivered across the Cisco Meraki portfolio. Our primary objective is to deliver IPv6 in a phased manner that is as simple and streamlined as possible to adopt for our existing and future customers.  IPv6 is one of our strategic cross-product initiatives and this is backed by engineering resources we have aligned to it.

We know you have asked for details, and we don’t yet have publicly-sharable specifics, but please rest assured that we have a comprehensive plan for IPv6 support that we are aggressively driving and are committed to providing continued updates on our progress.  As such, please expect the next update by the end of September 2019 on our IPv6 @ Meraki thread.

Thank you for your continued partnership,

The Cisco Meraki team

[Mod comment: We are marking this post as the solution to this thread. This is not because the issue is solved, but because we want to make the new location for updates from Meraki on this topic easier to access. That topic is: IPv6 @ Meraki.]

[CarolineS]

We are now locking this thread to further comments; stay tuned for updates on the new IPv6 @ Meraki thread.

UPDATE 14 July: We were over-zealous in our thread-locking. Opening this thread for further comments. Please also subscribe to the IPv6 @ Meraki thread for further updates from the Meraki team.

[MatsLarson]

---

@Meraki-PM-Team wrote:

We know you have asked for details, and we don’t yet have publicly-sharable specifics, but please rest assured that we have a comprehensive plan for IPv6 support that we are aggressively driving and are committed to providing continued updates on our progress.  As such, please expect the next update by the end of September 2019 on our IPv6 @ Meraki thread.

Thank you for your continued partnership,

The Cisco Meraki team

[Mod comment: We are marking this post as the solution to this thread. This is not because the issue is solved, but because we want to make the new location for updates from Meraki on this topic easier to access. That topic is: IPv6 @ Meraki.]

---

Looking forward to the promised update later this month.

[Bovie2K]

I have to say I about died laughing when Meraki had the Podcast last weekend on IPv6 and pretty much none of the hardware supports it. The podcast also made it sound like things were coming quickly. Fingers Crossed for the September update.

@Meraki-PM-TeamPLEASE BEG management for them to allow you to share more. We all love Meraki hardware its just getting harder and harder to recommend with this glaring hole. Some of the other major firewall stuff we know is coming like ikev2 and objects.

[JPAWELCHAK]

Trusting the September “Update” isn’t simply another delay. Anything less than a detailed roadmap to IPv6 will be simply insulting at this point.

[DHAnderson]

I am sitting my new deck (took almost all summer to build) on the last 80 degree day of the season in Minnesota.  It does not feel like the last day in September, but tomorrow the fall weather resumes.

I was hoping for an announcement today, but with a few working hours left, doubts are creeping in.  I know that software schedules slip, but some word of forward progress would be greatly appreciated!

- Dave

[AAVH]

The update is that there will be an update in December 2019. Status quo successfully maintained. 

[nikiwaibel]

@Meraki-PM-Team: thanks for letting us know you brought on board a top talented IPv6-taskforce. this is very well required and - at the same time - a pity that it has not happened earlier [2012 would have been the right time, but that's just my humble opinion and can't be changed 😉].

also, very much appreciated(!!), that you're aiming to to bring the full glory of IPv6 to the meraki stack, not just a FRITZ!Box like "experience".

but please, PLEASE, don't tell us the next update is going to be in 2 month, after letting us wait for so long already. this thread started ‎08-31-2017! any message from your IPv6-taskforce will help. let them speak, even if it is just a "hi, i am xxx from the IPv6-taskforce".

[JasonCampbell]

This whole issue is a joke at this point. I've lost all respect for Meraki at this point when it comes to major features missing. IPv6, SSLVPN, proper IPSEC /NAT support, they don't care; their indifference and wordplay games simply shows it.

I don't even know why I stick up for Meraki at this point. It's just rediculous the smoke and mirrors, and well as the ultimately unfulfilled promises that just dissapoint me more than anything.

Time to take a look around the vendor market at this point, to be honest. 

[JackTaugher]

REALLY?  They don't have it yet.  Come on .. this is Cisco!

[TheOldGuy]

It is Cisco, they are showing their true colors, and they don’t care what a customer actually needs rather than giving money to Cisco! 

[JasonCampbell]

Why don't you keep the updates on the thread WHERE EVERYONE IS DISCUSSING.

I'm sick and tired of Meraki trying to suppress this discussion. Unmark as solved, keep updates in this thread.

[MatsLarson]

---

@Meraki-PM-Team wrote:

Continuing our mission of simplifying powerful technologies, our aim with IPv6 is to not only provide basic functionality, but to solve key challenges that are preventing wider adoption of IPv6 in the enterprise by making IPv6 truly “Meraki simple”. To this end, we have been engaging with customers and gaining additional insights into wishes, expectations, and aspirations for the Meraki IPv6 implementation.

[emphasis added]

---

I think I speak for everyone in this thread when I say that at this point, we all would have preferred basic functionality to a series of empty promises and missed deadlines with nothing to show for it. It's great that you want to release a "Meraki simple" implementation, but that won't matter when everyone stopped using your product years ago because it didn't include even basic support for decades old internet standards.

You don't need to "engage with customers" to "gain additional insights" into your customers' wishes. Your customers told you their wishes loud and clear, right here in this thread, and you failed to deliver. Period. The IPv6 ship has sailed, and Meraki is at least 2 years too late to have been on it. They'll rightly be left behind with the rest of those who are too slow to adapt to an ever-evolving technological landscape. 

In other words: it's too late. September 2019 was too late to be just starting to put together a team to address this. December 2019 is too late for another update with no concrete progress. Add me to the list of people ripping out Meraki gear as fast as I possibly can and recommending everyone I talk to move to a better vendor while I do the same.

[JPAWELCHAK]

@Meraki-PM-Team Why would you move your updates on IPv6 to IPv6 @ Meraki when you have a suitable and active forum right here? To make matters worse, you appear to be stifling conversation around your glacial paced IPv6 progress (have yet to see evidence of any) in that IPv6 @ Meraki DOES NOT appear to have replies enabled. 😞

[MatsLarson]

I have just received my first report from an end-user of a service that is IPv6-only, and thus completely inaccessible from behind Meraki equipment.

Yet here we are, rapidly approaching the end of the "first half of December" window for the next "still working on it" update.

The licence expiration, and thus replacement of this dysfunctional equipment can't come soon enough. 

[zball8888]

it is 2021 and there is still no ipv6 support

[DHAnderson]

@zball8888 

Meraki has announced that they are working on it, so it is on the way.  

- Dave

[nikiwaibel]

howto sign up to the IPv6-MR public beta, as mentioned in https://community.meraki.com/t5/Full-Stack-Network-Wide/IPv6-Meraki/m-p/125342/highlight/true#M1871?

... it seems updating the firmware is sufficient (no "sign up", as such, required), but all APs that do not support the 28.x firmware have to be removed from that network. Otherwise you don't see the new firewall page. (I've had an old MR18 within the network).

[Djsky123]

Errrrmmm…. I could be wrong, but I just randomly, out of the blue, tried my vpn to my MX using EE (who provide ipv6) and it WORKED!!!! So, it looks like things are on their way to an actual useable service!

[cmr]

@Djsky123 what firmware are you running and do you see an IPv6 public address?  On 17.2.1 you see IPv4 and IPv6 public addresses for each WAN connection.

[Djsky123]

I’m on 14.53. Not beta testing or anything.

I just connect to my static ipv4 address…. But this would always bomb out with a “client error” as the client always had a ipv6 address and the mix would refuse connection…. But now it works!!!! I’m Happy! 🙂

[cmr]

I'm guessing EE have got IPv6 to IPv4 working properly then, which is good 👍

[GIdenJoe]

Hey, over two years ago I used to work for a Belgian ISP as technician and they were on the forefront of IPv6 in pretty much entire Europe.
They also use DHCP-PD for assigning prefixes to customers.

They also had their own modem/routers that supported a nifty feature called hiërarchical prefix delegation.
That means the ISP assigns a /56 prefix on the WAN side of that modem/router and that further could give out /60 prefixes to downstream routers so they could further subdivide those into /64 client networks.

I believe for the global unicast addressing that support on all L3 devices for hiërarchical prefix delegation is crucial to deal with dynamic addressing.

If Meraki is to support features like this in the future it is also important that just like on a cisco ISR you can define the subnet part of each of your subnets. So you dynamically get your global prefix from upstream and you put the subnet part in it which is fixed to your preference.

[Uberseehandel]

I think most of us are planning on being allocated a /48 or /56 address or better, rather than a /64.

[Mitch_Hennessy]

That sounds suspiciously like the (subset of) HomeNet protocol -- a good idea that was thought of and "worked on" far too late in the IPv6 lifecycle for most enterprise-y products...at least to my knowledge...to make use of.

It would work for connections with dynamic prefixes (since they're delegated), as long as all the clients were SLAAC'd and you didn't have any managed endpoint requirements or non Windows 10 devices (for RDNSS) or any policy routing requirements (MX SD-WAN) for separate WAN connections or any servers that don't support...ummmmm...generic prefixes, I think?  The mechanism that lets an admin specify a host interface ID, but accepts any new prefixes when the RAs change?  The router/FW ACLs would also have to support that in the case of dynamic prefixes as well.

Thinking it through, I'd think for this to have hope of working the way IPv4 with Merakis do now, MXes would have to support pretty much every IPv6 mechanism defined by a non-superceded RFC; NPTv6 (if you want to use it), "Generic Prefix" (if you want to use it), hierarchal DHCP-PD/v6, ULA (if you want to use them), some sort of prefix-variable managed DHCPv6 delegating server with short DUID lease times where the scope prefixes change along with the upstream delegated prefixes received from (each) ISP(s) so that clients can renew leases on new prefixes without much downtime...or something.  At least bring some kind of auditing for any org that needs host ID tracking but doesn't want to sell their SMB employee kidney pairs for something like InfoBlox or Bluecoat IPAM.

The problem...errrrr..."challenge"....is keeping the "Meraki-ness".  This seems kinda feasible with something that lets you connect directly to the device to do the entire device configuration -- in the sense that you don't need a working IPv6 Internet connection to the cloud in order to configure your device to give you the IPv6 Internet access you'd already need in order to configure it -- again, that assumes if the local device admin interface remains roughly the same.  At the very least, each MX local admin page would have to provide a field that allows an admin to specify the prefix hint and length for DHCP-PD for each WAN-capable interface.  Or maybe MXes would just be initially configurable and managed over just IPv4 to connect to the Dashboard and then v6 access is configured then and isn't "live" until everything is validated via some WAN connectivity test from the client machine behind it (and any other L3 devices it might hierarchically be behind).  I mean, why not?  We're going to be dual-stacked for the foreseeable future, so nothing says we have to completely get rid of v4 usage.

Actually, that last part might not be ideal given current source address selection policies of most modern client OSes.  As soon as v6 global addresses are assigned or SLAAC'd by clients, they'll prefer them, even if the prefixes are not fully routable, and may have to "fail" to v4, which would negatively affect user sessions depending on how Happy Eyeballs behaves for each client.

But I'll be quite honest, I'm not sure how most of the above translates to a Dashboard interface.