The SMC D3G modem is by most accounts on this board (and publically elsewhere, and my own experience) a solid IPv4 Cable modem, although it does not support the newest Comcast data speeds (since it only supports 4 channels) Do NOT mistake the SMC D3G for any of it's predecessor SMC cable modems which have varying reports of success.
However the D3G's IPv6 is atrociously broken.
As a professional hoster (this is NOT a hobby for me), I am also interested in making IPv6 hosting available on my servers. There are 6 major barriers to this:
1) I must be up 24x7 (or as close to it as possible) and it must be reliable. I cannot tolerate a cable modem that has slowness or disconnections under load or any of that nonsense that a typical residential Internet user can "gloss over" I even have a dedicated cable to the street with NO cable TV taps or any of that garbage that would reduce signal. And I regularly monitor signal strength and graph it. All my stuff is on a UPS and I also have a generator. What I'm trying to explain here is I have invested far more money and time into making this a reliable connection than a typical residential user would ever do. And my return for this money and effort is a highly reliable connection that has had about 15 minutes of unplanned downtime over the last 17 months.
2) I must have static public IP addresses on my servers, I happen to have a /28 subnet of public IPv4 from Comcast. Because of this I a) have to spend extra money for Comcast Business Service and b) am forced by Comcast to rent a modem from them from their limited selection of devices.
3) I cannot run a "real router". If I had my way I'd have a Cisco enterprise router dropped in if I could. But, Comcast requires that any static IP subnet have one of it's numbers on the LAN interface of their modem, and they do not recognize routing for IPv4 subnetting. You cannot take a /28 and split it into 2 /29's, burn one of those in between a Comcast-supplied modem and an ethernet port of a router, then put the other /29 behind your router. AN ADDRESS TRANSLATOR LIKE A LINKSYS WHATEVER IS NOT A REAL ROUTER. It is a toy router. I use them at customer sites but I don't delude myself that they are actual routers. Incidentally this also means for me to get netflow data I have to do weird ugly things like run strange software on promiscious LAN interfaces with managed switches with monitoring ports defined. Thanks, Comcast......NOT!!
4) Comcast does not (yet) support static IPv6 on their network. Fortunately their IPv6 DHCP server that assigns IPv6 to their cable modems seems to prefer to leave a subnet alone once it's assigned, unless your offline for a long time or something. So you can pretend you have a static IPv6 assignment if you have a highly reliable network setup
5) Comcast does not give PTR records out for dynamically assigned IPv6. This means that you cannot put a mailserver on IPv6 on a Comcast connection because some recipient mailservers on the Internet will refuse to accept incoming email from IPv6 addresses that do not have PTR records. And one of these is comcast.net's very own mailservers. Yes indeed folks, Comcast's mailservers WILL NOT accept incoming mail from a customer-owned mailserver that is assigned IPv6 from them on their very own network!!! Talk about bass-ackwards stupidity!! The fact that the email RFC's do NOT require PTR records for mailservers is apparently lost on the Comcast mailserver admin.
6) Because I am running servers on the public Internet they ALL have firewalling ON THE HOST. Any kind of firewalling on the cable modem IS INTERFERENCE AND IS UNWANTED.
Now that you (hopefully) have all of that in mind, folks, I will outline what Ihad to do to get LIMITED IPv6 serving to work for my primary website - http://www.portlandiacloudservices.com
1) First was modem choice - this was a no-brainer. The SMC. It was proven (4 years now) it did NOT have an unwanted wifi access point in it (which wasn't really an issue since my gear is all in a 42U cabinet which makes a great Faraday cage) and it has few complaints out in the wild about it (other than a handful from people who obviously were on special situations where the modem wasn't to blame, or they were obviously not knowledgeable about cable issues) As much as I wanted IPv6, that had to take second fiddle to reliability.
2) Next was IPv6 availability. I've periodically logged into my SMC over the years, observing it's stats. Sometime very late last year or early this year IPv6 suddenly started showing up in it's stats so I knew Comcast had finally rolled IPv6 out in my area
3) Next was protection. There's bad people on the Internet who like to try breaking into servers. In my case I run FreeBSD and Linux, both of which have very good firewalling in the operating system for both IPv4 and IPv6
4) Next was services. Until PTR records are available, email over Comcast native IPv6 was not going to happen, a tunnel provider was the only option there (and I already had that going from a few years ago) So that left http and https.
5) Next was configuration. As a hoster the key "buttons" in my SMC configuration for IPv4 are the following:
LAN->IP Setup, IPv6 Setup, Static Routing, Filtering, Switch Controls - ALL set to their defaults - that is, no additional configuraiton beyond what is there from a factory reset and provision by Comcast.
Firewall->Firewall Options - set to Disable Firewall for True Static IP Subnet Only. Set Disable Gateway Smart Packet Detection. Unset Disable Ping on WAN Interface
This is the "standard recommended" setting for IPv4 public subnets. The modem STILL acts as a DHCP server and will serve out 10.x.x.x numbers but your running servers which are statically numbered behind it so you can ignore that.
When IPv6 became live in my area, I gave it a few months to settle then I enabled IPv6 on my FreeBSD test system. It picked up an autoconfigure address from the SMC and I was able to ping6 www.microsoft.com and traceroute6 to various places. BUT, there was NO WAY that I could tracerout6 or ping6 to the IPv6 address assigned to my system. trace6's simply blocked at the SMC modems WAN IPv6 address
Like a backwards Roach Motel, you can go out but you can't come in!!!
So I investigated and here is what has to be done on the modem.
For starters, in the SMC interface under
Firewall-> Port Configuration there is a "Allow public acces to LAN side IPv6 hosts" link. Clicking this gives you a Disable all IPv6 access rules button. How convenient! Except that IT IS BROKEN!!! Clicking that button DOES NOT DO ANYTHING. it MAY do something IF your 100% dynamic with NO static IP and are using the SMC as a translator - but NOT if you have the Disable Firewall for True Static IP Subnet checked - which is a requirement for a static IPv4 subnet.
You have to leave this unchecked, AND you have to enter a hostname with a MAC addresss, AND once that is entered you have to enter an IPv6 address. I used the autoconfigure address that my host obtained from the SMC modem for that.
BUT, that is NOT all. EVEN DOING THAT it is STILL BROKEN. There is ONE OTHER CHANGE to make.
In the modem's configuration, go Firewall DMZ. Click Enable DMZ Host. Put in the IPv4 address of the IPv6 host that you want to make accessible to the Internet and save it. The modem will reboot and do things for a while then come back.
YES I KNOW THIS IS CRAZY! BUT IT WORKS. Of course, it ONLY works for the ONE host that your wanting to make accessible to IPv6 traffic on the Internet.
Anyway, I very much hope that this helps other people who are using static IP addresses with these cable modems. I think it is a shame that SMC apparently has so little regard for their hardware that they cannot provide debugged firmware to Comcast for deployment, particularly since we are 99.8% of the way there to having a working IPv6 solution, and hopefully this little guide of mine will increase pressure on Comcast to ignite a large blowtorch under SMC to do so.
I doubt such a blowtorch will be ignited. The SMCD3G is likely to be deprecated soon, much as the SMC8014 D2.0 gateway was a few years ago. It is unfortunate, as it is a solid unit, notwithstanding its technical limitations (4x4 channel bonding, primarily).
I have a followup on my original post,
Unfortunately, while the procedure documented above does work for allowing IPv6 access, I have also found the same major bug that Jonathan Briggs found back in March and posted on this forum - which is that the SMC becomes unreliable and reboots itself every 6 hours or so when the IPv6 code is enabled.
In summary, the SMC can ONLY be used reliably for IPv6 connections initiated from the inside, to the outside, - installing an exception in the IPv6 firewall in the SMC to allow outside-to-inside IPv6 connections causes the SMC to reboot itself every 6 hours or so.