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

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

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

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

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

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

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