Dual-Stack on SMC D3GCCR and Cisco DPC3939B

---

@mltorley wrote:

Regardless, "super-simple for the customer" may make sense for home or SOHO customers, but not so much for an enterprise with in-house IT.  Bit of a scaleability issue.

---

I would very much agree

My guess is that the vast majority of customers who purchase "Comcast Business" in the HFC (coaxial-based) form are likely home businesses/small businesses, often with no dedicated IT staff (or a rather small one). Customers who want advanced control over routing functions, etc. generally tend to be larger corporations or enterprises that end up ordering either the Comcast fiber-based services ("Metro ethernet"), or other more specialized ISP connections.

That said, there are many small business IT personnel that would love more control over more features (I am one of them!)

---

@train_wreck wrote:

My guess is that the vast majority of customers who purchase "Comcast Business" in the HFC (coaxial-based) form are likely home businesses/small businesses, often with no dedicated IT staff (or a rather small one). Customers who want advanced control over routing functions, etc. generally tend to be larger corporations or enterprises that end up ordering either the Comcast fiber-based services ("Metro ethernet"), or other more specialized ISP connections.

That said, there are many small business IT personnel that would love more control over more features (I am one of them!)

---

Well, I work for a fairly large subsidiary of a very, very large (top 10 globally) corporation, but our branch offices face limited options for connectivity.  For two of the twenty-some-odd offices, comcast is both the fastest and most cost-effective option available.  Much better than the bundle of T1's we had been stuck with.  IPv6 isn't even available at most of the rest.

It just happens that one of those two offices is where our one networking guy (me) is starting to build out AD, using a Win Server router instead of linux for the first time and pulling some hair out.

Anyhow, Comcast brought me a netgear, which claims to be handing out a /56 prefix, but advertises /64 even with the "Customer defined prefix" set to the same (seems to do exactly nothing).

RA sends - 2601:xx:xxxx:xx00::/64

Even if custom prefix set to 2601:xx:xxxx:xx00::/56 

It also sets its link-local address as the gateway to route 2601:xx:xxxx:xx00::/56, which I'm pretty sure is also wrong.  

You have one of these, right?  Any advice?  

EDIT: Also tried with /60 custom prefix (2601:xx:xxxx:xx30::/60).  Still advertised as /64, still makes itself the gateway for the /60

Hi mltorley,

I have one of these and in fact http://www.portlandiacloudservices.com has an IPv6 address that is assigned from it.  I also have it setup to hand out additonal IPv6 subnets.  I also run a /28 of static IPv4.

I can walk you through my config if you like, in this forum.  But, before you get started you have to understand that you will NEVER get it to work properly using a Windows Server as your router to the rest of the world.  I use a Cisco 1800 router, you MIGHT get a VERY CURRENT version of dd-wrt running on a NV64k or later like a recent Linksys or Netgear with a 400Mhz CPU to do it - and you can get Ubuntu 14 to work out of the box as a router - Ubuntu 12 has some bugs but can be knocked into submission - but forget using Windows Server as a router.

Here's the overview:

The situation with IPv6 is as follows:

Comcast is currently NOT handing out IPv6 static IP addresses.  The problem is that
most (if not all) of their CPE modem devices are badly busted with IPv6.  The
biggest problem is assignment of local smaller networks is broken on all of them
except the Netgear - and that device has problems with SIP ALG.

However they ARE handing out dynamically assigned IPv6 subnets to their routers and
their routers will pick up one /56 from Comcast.  Because these are dynamically
assigned Comcast will not create PTR records for them so it is not possible to use
them for outgoing email.

The Netgear firmware works after a fashion with IPv6.  For SLAAC it works perfectly if
all devices are plugged directly into it.  However for subnetting IPv6, you cannot
enter a static IPv6 route into it.  So you cannot manually subnet using a combination of
SLAAC and static routes.

You can use Prefix Delegation with IPv6 on the Netgear.  You must turn on DHCPv6
then your router behind it must make a DHCP PD request.

With IPv6 it does not hand out default gateway IP addresses using DHCP.  Your host must listen
to route advertisements.  If you have a router the router must have a default IPv6 gateway
hard coded into it because routers don't pay attention to IPv6 default GW route advertisements

If you don't want to go here and you want to stick with Windows Server, then your going to have to

figure it out by yourself.  I am not going to assist in helping someone beat their head against a

stone wall.

Well, I know there would be problems if the prefix changes (though the gateway does allow me to set a /56, I don't know how static it is), but now I'm determined to make it work.  

Windows is getting the default routes from the gateway's RA, including the /56 from Comcast.  And the ICMPv6 packets that the gateway responds with to tell me it won't accept a packet I send route back the sending client just fine.  So I'm able to route to and from the gateway.  

As I understand it (admittedly limited), packets with source prefix matching the assigned /56 should be sent to the gateway's link-local as it is the next hop for said prefix on the way out.  But the gateway kicks them back even when the originating interface is directly connected to it.  So I don't think it's a routing issue at all, the gateway just won't accept the packets.  

I've even tried assigning my external interface addresses with /56 and /60 prefixes with and without the 64th bit set (my math could be off - last hex digit of prefix set to 0 or 1.  gateway has 0).  No matter what the prefix length, the gateway kicks it back if that last bit is flipped.  What I gather from the IETF's docs (before they put me to sleep) tells me this is not how it's supposed to work.  So all I can come up with is that the filters are set to match all 64 bits instead of 56.

Oh, and thank you.  You have already provided several orders of magnitude more information than anyone at comcast has.  Hell, they never even once mentioned routing tables, even when I asked.  They did offer to send me another Cisco, which as you pointed out won't do smaller networks at all.  Thank god we don't need SIP or PTR records!   

I'd just order a working modem if we didn't need static IP4. I can't believe Comcast has gone years without providing equipment that works.  

No, I can.  After all, they are the company that swore to me there was no data cap, then told me it was being increased to 300gb/month six months later.  (sorry to vent, I'm very annoyed with them)

"..Well, I know there would be problems if the prefix changes (though the gateway does allow me to set a /56, I don't know how static it is),.."

The gateway will not work at all if you do anything to statically set any IPv6 parameter in the gateway

"..Windows is getting the default routes from the gateway's RA, including the /56 from Comcast..."

Please print your route table.  At the Windows command line type

route print

and copy and paste the IPv6 Route Table to a post here.  (you can change the IP addresses if you want in a

trivial manner, change an a to a b or some such if your afraid of posting real IPs)

"...And the ICMPv6 packets that the gateway responds with to tell me it won't accept a packet I send route back the sending client just fine.  So I'm able to route to and from the gateway.  

As I understand it (admittedly limited), packets with source prefix matching the assigned /56 should be sent to the gateway's link-local as it is the next hop for said prefix on the way out.

correct

"..But the gateway kicks them back even when the originating interface is directly connected to it.  So I don't think it's a routing issue at all, the gateway just won't accept the packets..."

What is the gateway - the comcast netgear?  Or the comcast cisco?  What is the comcast router model? 

Do a print screen of the settings and post here.

"..I've even tried assigning my external interface addresses with /56 and /60 prefixes with and without the 64th bit set (my math could be off - last hex digit of prefix set to 0 or 1.  gateway has 0).  No matter what the prefix length, the gateway kicks it back if that last bit is flipped.  What I gather from the IETF's docs (before they put me to sleep) tells me this is not how it's supposed to work.  So all I can come up with is that the filters are set to match all 64 bits instead of 56..."

Do not statically assign anything on windows in IPv6 leave everything on windows set to automatic or it will NOT work at all!!!!!!!  This is true EVEN IF you are running your own router and your windows system is behind it!!!   Can you explain your network setup a bit better - is this a single cable modem with a single windows system running internet sharing?  Do you have a single static IPv4 IP or multiple ones?

Oh, and thank you.  You have already provided several orders of magnitude more information than anyone at comcast has.  Hell, they never even once mentioned routing tables, even when I asked.  They did offer to send me another Cisco, which as you pointed out won't do smaller networks at all.  Thank god we don't need SIP or PTR records!   

I'd just order a working modem if we didn't need static IP4. I can't believe Comcast has gone years without providing equipment that works.  

No, I can.  After all, they are the company that swore to me there was no data cap, then told me it was being increased to 300gb/month six months later.  (sorry to vent, I'm very annoyed with them)

Here's the routing table as it is right now.  There are artifacts from my last round of attempts, but the routes from the gateway are there.  

Interface 12 is WAN, 13 is LAN, 14 and up are VPN, 6-to-4 and direct access interfaces that aren't doing anything at the moment.  I've had them on and off.

You'll also see a mix of manual and autoconf'd addresses.  I think these are the routes that allowed me to ping (but get the ingress/egress reply) the gateway from the LAN, but I'm not advertising them internally, so I can't double check.

12 ff00::/8                                                    ::
13 ff00::/8                                                    ::
1 ff00::/8                                                      ::
12 fe80::rout:er:wan:ifce/128                  ::
13 fe80::rout:er:lan:ifce/128                    ::
15 fe80::200:5efe:my.stat.ici.p4/128      ::
14 fe80::ffff:ffff:fffe/128                              ::
16 fe80::5efe:int.lan.ip.4/128                  ::
14 fe80::/64                                                ::
12 fe80::/64                                               ::
13 fe80::/64                                                ::
13 2601:xx:xxxx:xx37::1/128                      ::
13 2601:xx:xxxx:xx37::/128                       ::
13 2601:xx:xxxx:xx37::/64                          ::
12 2601:xx:xxxx:xx01::/64                              :: <-testing
12 2601:xx:xxxx:xx00:rout:er:wan:ifce/128 ::
12 2601:xx:xxxx:xx00::beef/128                       :: <-testing
13 2601:xx:xxxx:xx00::abcd/128                     :: <-testing
12 2601:xx:xxxx:xx00::/64                                  ::
12 2601:xx:xxxx:xx00::/60                                  ::  <-testing
12 2601:xx:xxxx:xx00::/56                              fe80::gate:way:link:local  <-From RA
13 2601:xx:xxxx:xx00::/56                              ::
14 2001::/32 ::
1 ::1/128 ::
12 ::/0                                                                 fe80::gate:way:link:local  <- From RA

I've tried with the prefix and DHCP unchecked as well, this is how it is right now.

From the Gateway's Status page:

I have one static IP4 address.

The layout is like this:

Gateway - Server 2012r2 RRAS - LAN (managed switch)

When I have router and route advertising enabled on the LAN, everything can ping the gateway but only the WAN interface can ping through it.

I do not have "enable unicast" turned on on my Netgear but I do not think it matters much either way.

As for your route tables, they are not showing that a DHCP PD request was made or received

Please set your LAN and WAN IPv6 interfaces to obtain automatically.  Remove all static IPv6 anything.

Turn on DHCP client logging - read this:

http://superuser.com/questions/217287/how-do-i-open-the-dhcp-client-log-on-windows-7

Copy the System Delegated Prefix from your Netgear interface screen to

http://www.gestioip.net/cgi-bin/subnet_calculator.cgi

Select IPv6 and click calculate.  There should be a link to 16 /60s click it

The highest /60 in the list is the one the Netgear will hand out in response to a proper PD request.  Note down that

subnet list.

Plug in the WAN interface of the Windows box to the Netgear.  Look at the DHCP client log on the Windows sytem.  Did it request a prefix from the Netgear?  Did it get one back?  The prefix should have been on that list you got from gestioip.net was it?

Turn on RA logging in Windows.  Look here:

https://technet.microsoft.com/en-us/library/dd458953.aspx

Does the RA service show it's advertising the correct prefix?

In summary - here is the problem in a nutshell - the Netgear is a black box - you don't have access to it's router logs - so you cannot see what it's getting from the Windows box - you can't see if it's installing the correct static routes in it's IPv6 route table - you can only guess.

If you have your OWN router that has a complete set of logs - then your problem is like a sighted person leaving a blind man around.  It can be done but it's not easy.

If your own router is a Windows box that issues no logging at all - then it also is just a black box - so now you have 2 black boxes you have zero visibility into that your trying to get working - it's like the blind leading the blind.

One last thing - you can always use an actual router - like a cisco, or even a linux box with better logging on it - to establish the netgear is working - then put the windows box in as a router and see if you can get it working.

If I can, I'll give it a shot.

Things like removing any static addresses will have to wait till I can reboot without causing trouble for the office.

---

 

Does the RA service show it's advertising the correct prefix?

 

 

---

I can do one better - Here's an RA packet I capped with wireshark:

Frame 2: 174 bytes on wire (1392 bits), 174 bytes captured (1392 bits) on interface 0
Ethernet II, Src: Netgear_ed:1d:32 (xx:xx:xx:xx:1d:32), Dst: IPv6mcast_01 (33:33:00:00:00:01)
Internet Protocol Version 6, Src: fe80::xxxx:xxxx:feed:1d32, Dst: ff02::1
Internet Control Message Protocol v6
   Type: Router Advertisement (134)
   Code: 0
   Checksum: 0xebb6 [correct]
   Cur hop limit: 64
   Flags: 0x40
   Router lifetime (s): 1800
   Reachable time (ms): 0
   Retrans timer (ms): 0
 ICMPv6 Option (Source link-layer address : xx:xx:xx:xx:1d:32)
   Type: Source link-layer address (1)
   Length: 1 (8 bytes)
   Link-layer address: Netgear_ed:1d:32 (xx:xx:xx:xx:1d:32)
 ICMPv6 Option (Prefix information : 2601:xx:xxxx:XX00::/64)
   Type: Prefix information (3)
   Length: 4 (32 bytes)
   Prefix Length: 64
   Flag: 0xc0
   Valid Lifetime: 345600
   Preferred Lifetime: 345600
   Reserved
   Prefix: 2601:xx:xxxx:XX00::
 ICMPv6 Option (Route Information : Medium 2601:xx:xxxx:XX00::/56)
   Type: Route Information (24)
   Length: 3 (24 bytes)
   Prefix Length: 56
   Flag: 0x00
   Route Lifetime: 3600
   Prefix: 2601:xx:xxxx:XX00::
 ICMPv6 Option (Recursive DNS Server 2001:558:feed::1 2001:558:feed::2)
   Type: Recursive DNS Server (25)
   Length: 5 (40 bytes)
   Reserved
   Lifetime: 60
   Recursive DNS Servers: 2001:558:feed::1
   Recursive DNS Servers: 2001:558:feed::2

I have yet to find a way to get windows to actually request  a PD.  All I've found on the subject is that Vista needs ICS turned on for it (I'm wary of doing so on a server, especially since... vista.  Don't know enough about ICS really.  I'll rectify that).  

DHCP6 Client event log is just a series of these:

Router Advertisement settings have been changed on the network adapter 12. The current M - Managed Address Configuration flag is false and the O - Other Stateful Configuration flag is true. User Action: If you are seeing this event frequently, then it could be due to frequent change in M and O flag settings on the router in the network. Please contact your network administrator to have it resolved.

Though I have to go back weeks to find any where the settings actually changed.  Except for just now when I changed the interface settings again.  The cmdlets are strange, had to set advertising, M, O, and dhcp on, then O on again, then turn off advertising (which sets O back off) in order to get ND and DHCP traffic going. 

Right now, Server's neighbor ads have router and override flags set.  

Server solicits:

Option Request
Option: Option Request (6)
Length: 8
Value: 0018001700110020
Requested Option code: Domain Search List (24)
Requested Option code: DNS recursive name server (23)
Requested Option code: Vendor-specific Information (17)
Requested Option code: Lifetime (32) 

Gateway replies with the values for those 4 options.

Just in case, Here's the interface config (get-netipinterface | fl).  

InterfaceIndex : 12
InterfaceAlias : WAN
AddressFamily : IPv6
Forwarding : Enabled
Advertising : Disabled
NlMtu(Bytes) : 1500
AutomaticMetric : Enabled
InterfaceMetric : 10
NeighborDiscoverySupported : Yes
NeighborUnreachabilityDetection : Enabled
BaseReachableTime(ms) : 30000
ReachableTime(ms) : 35500
RetransmitTime(ms) : 1000
DadTransmits : 1
DadRetransmitTime(ms) : 1000
RouterDiscovery : Enabled
ManagedAddressConfiguration : Disabled
OtherStatefulConfiguration : Enabled
WeakHostSend : Disabled
WeakHostReceive : Disabled
IgnoreDefaultRoutes : Disabled
AdvertisedRouterLifetime : 00:30:00
AdvertiseDefaultRoute : Disabled     
CurrentHopLimit : 64
ForceArpNdWolPattern : Disabled
DirectedMacWolPattern : Disabled
EcnMarking : AppDecide
Dhcp : Enabled
ConnectionState : Connected
PolicyStore : ActiveStore
CompartmentId : 1

Until you can get a PD request packet issued you are dead in the water.  No amount of mucking around with RAs is going to do anything.

The fundamental problem here is that the Comcast router/modem MUST enter an IPv6 route in it's route table for one of those /60s pointing that /60 to your Windows box..  It can only do that by delegating a /60 to a router that uses DHCPv6 to request a PD.  The Comcast router is not at all interested in what you are sending it via RA.  It pays no attention to RAs.  And I believe it also pays no attention to static route entries made into the static route customer interface and I am not sure that interface will even take IPv6 static route entries.

I have also read the same thing that Windows will not issue a DHCPv6-PD request unless ICS is turned on.  The problem here of course is that when you turn ICS on you turn the Windows box into an address translator.  So, IPv4 subnet routing is out of the question.  And who knows if the Windows box, when acting as an ICS system, will attempt to "translate" the IPv6 or not.  Personally I believe that Microsoft is probably not even testing ICS code anymore since you can get a brand new wireless N router for under $200 that will make a better address translator and a faster router than any Windows system ever could.

I have several customers with remote offices, some with many remote offices. In all of those cases I've deployed the Cisco RV320's  (I used to deploy the RVD4000s but those are obsolete)  It almost always requires a renumber out of the 192.168.1 subnet at the remote office and I've gotten some squawking in the past over it.  That allows me to setup a gateway2gateway IPSec VPN from the remote site and then the remotes can join the domain like normal regular folks.  In some of those setups the larger remote offices do have Windows servers which of course are also joined to the domain.   The RV320's a stable, their IPSec VPN's are highly stable, and they will readily establish a VPN to a Cisco ASA firewall.  For the largest customers I have I use ASA's at the main office and the largest one has over 70 remote offices, all with dedicated IPSec ZVPNs coming into an ASA.

Does anyone know if the Cisco 3941 prefix delegation issues have been corrected at this time?  We're curently using the Netgear with success, but it periodically freezes requiring a power cycle.  The Cisco 3941 seems to be the only replacement available through Comcast, but we want to be sure that PD support is working properly before making the change.  

No, it doesn't work.

The DCP3941 is worthless when it comes to IPv6.  The issues:

1) IPv6 prefix delegation doesn't work.

2) The firewall code randomly drops TCP connections. You can disable the firewalling for IPv4, but even though the GUI gives you options to do this for IPv6, it doesn't actually completely turn off the firewall.  The consequences is that Google and other IPv6 services tend to hang while the browser tries to use what it thinks is a currently open connection.

From what I can tell, Comcast is likely not serious about fixing either issue, so my suggestion is to turn off IPv6 unless you have an actual business need for it.  I know that's lousy, and it absolutely pains me to say that since I am as big of an IPv6 advocate as anyone - but I need my internet connection to work.

GSFL, freezing isn't a known issue with those Netgears.  It is, however, a known issue with cable lines that have signaling issues.  And it is also a known issue with some AC power adapters particularly as they age.

I would not write off the Netgear just yet.  Call support and make sure that you are getting good signal and that they are seeing good signal.  Maybe an attenuator or a splitter is failing.   And find an AC adapter that is the same voltage and current and polarity as the Netgear one and try swapping it for a few days.