cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

WE Need IPV6 Support in MX

SOLVED
Here to help

Re: WE Need IPV6 Support in MX

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.

Getting noticed

Re: WE Need IPV6 Support in MX

 

Selection_823.png

 

Getting noticed

Re: WE Need IPV6 Support in MX

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.

Meraki Alumni (Retired)

Re: WE Need IPV6 Support in MX

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.

Here to help

Re: WE Need IPV6 Support in MX

too little too late

Here to help

Re: WE Need IPV6 Support in MX

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. 

Getting noticed

Re: WE Need IPV6 Support in MX

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.
Meraki Alumni (Retired)

Re: WE Need IPV6 Support in MX

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

Re: WE Need IPV6 Support in MX


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

 

 

Cohort Networks Inc.
Your Business. Connected.
Getting noticed

Re: WE Need IPV6 Support in MX

@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.
Here to help

Re: WE Need IPV6 Support in MX

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.

Here to help

Re: WE Need IPV6 Support in MX

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.

Getting noticed

Re: WE Need IPV6 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."

 

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

Getting noticed

Re: WE Need IPV6 Support in MX

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.

 

 

Here to help

Re: WE Need IPV6 Support in MX


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

Here to help

Re: WE Need IPV6 Support in MX


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

Here to help

Re: WE Need IPV6 Support in MX


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

Highlighted
cmw
Conversationalist

Re: WE Need IPV6 Support in MX

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

Getting noticed

Re: WE Need IPV6 Support in MX

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
Conversationalist

Re: WE Need IPV6 Support in MX

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

 

Getting noticed

Re: WE Need IPV6 Support in MX

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.

Cohort Networks Inc.
Your Business. Connected.
Getting noticed

Re: WE Need IPV6 Support in MX


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

Cohort Networks Inc.
Your Business. Connected.
cmw
Conversationalist

Re: WE Need IPV6 Support in MX

Thanks @Cohort_Networks, 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

Getting noticed

Re: WE Need IPV6 Support in MX

@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

Here to help

Re: WE Need IPV6 Support in MX

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

Re: WE Need IPV6 Support in MX

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!

 

Conversationalist

Re: WE Need IPV6 Support in MX

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!

Here to help

Re: WE Need IPV6 Support in MX

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)

Getting noticed

Re: WE Need IPV6 Support in MX

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.

Getting noticed

Re: WE Need IPV6 Support in MX

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

Getting noticed

Re: WE Need IPV6 Support in MX


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

Cohort Networks Inc.
Your Business. Connected.
Kind of a big deal

Re: WE Need IPV6 Support in MX


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

Robin St.Clair | Principal, Caithness Analytics | @uberseehandel
Getting noticed

Re: WE Need IPV6 Support in MX


@Cohort_Networks 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 😞

Here to help

Re: WE Need IPV6 Support in MX

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

Conversationalist

Re: WE Need IPV6 Support in MX

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.

Getting noticed

Re: WE Need IPV6 Support in MX

@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)?

Cohort Networks Inc.
Your Business. Connected.
Getting noticed

Re: WE Need IPV6 Support in MX

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.

Conversationalist

Re: WE Need IPV6 Support in MX

Thanks for your response @Cohort_Networks. 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.

Conversationalist

Re: WE Need IPV6 Support in MX

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

Re: WE Need IPV6 Support in MX

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.

Getting noticed

Re: WE Need IPV6 Support in MX

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.

 

 

Here to help

Re: WE Need IPV6 Support in MX

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

Conversationalist

Re: WE Need IPV6 Support in MX

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.

Here to help

Re: WE Need IPV6 Support in MX

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!

Here to help

Re: WE Need IPV6 Support in MX

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

Re: WE Need IPV6 Support in MX

 

as you can see here (Switch / ACL)

Selection_999(1216).png

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.

Getting noticed

Re: WE Need IPV6 Support in MX

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.

 

Getting noticed

Re: WE Need IPV6 Support in MX

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.

Getting noticed

Re: WE Need IPV6 Support in MX

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. 

Getting noticed

Re: WE Need IPV6 Support in MX


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

Cohort Networks Inc.
Your Business. Connected.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.