Non-dhcpv6 prefix delegation configured network Comcast modem/router configuration setting for Router Advertisement (RA) configured route

I've done a little more research on this.  Here is what I believe is correct.  The bottom line is that the Comcast modem doesn't seem to be able to process Router Advertisements that contain routing information.  

Below is a sample tcpdump listening on the interface connected to the cable modem.  The cable modem to our router's network address is A:B:C:E300::/64.  I have a static subnet established on my LAN as A:B:C:E362::/64. 

Notice the Neighbor Solicitation messages that are coming from the cable modem.  In this case I am pinging (ICMPv6) google.com from a machine on the E362::/64 subnet

First we have the ping:

19:27:05.227667 IP6 (hlim 9, next-header ICMPv6 (58) payload length: 40) A:B:C:e362:4af:a0ec:95ee:7638 > 2607:f8b0:4005:813::200e: [icmp6 sum ok] ICMP6, echo request, seq 9322

Then what looks like an attempt to deliver the reply (it is doing a NS for the above source address):

19:27:05.240462 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::10:18ff:fe16:6f7d > ff02::1:ffee:7638: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has A:B:C:e362:4af:a0ec:95ee:7638
          source link-address option (1), length 8 (1): de:ad:be:ef:be:ef
            0x0000:  deaf beef beef

It doesn't get a Neighbor Advertisement response, so it tries again:

19:27:06.271533 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::10:18ff:fe16:6f7d > ff02::1:ffee:7638: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has A:B:C:e362:4af:a0ec:95ee:7638
          source link-address option (1), length 8 (1): de:ad:be:ef:be:ef
            0x0000:  deaf beef beef

Instead of forwarding the packet to the router's interface, it is trying to find this address on the e300 subnet.  It is pretty clear that the comcast modem doesn't know where to route this even though there is a route being specified as part of the router advertisement.  Here is a sample:

19:27:07.692384 IP6 (flowlabel 0x48c17, hlim 255, next-header ICMPv6 (58) payload length: 80) fe80::3039:3834:3233:6163 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 80
        hop limit 64, Flags [none], pref medium, router lifetime 15s, reachable time 0ms, retrans time 0ms
          prefix info option (3), length 32 (4): A:B:C:e300::/64, Flags [none], valid time 86400s, pref. time 14400s
            0x0000:  4000 0001 5180 0000 3840 0000 0000 A
            0x0010:  B C e300 0000 0000 0000 0000
          route info option (24), length 24 (3):  A:B:C:e362::/64, pref=high, lifetime=86400s
            0x0000:  4008 0001 5180 A B C e300 0000
            0x0010:  0000 0000 0000
          source link-address option (1), length 8 (1): de:ad:be:ef:be:ef
            0x0000:  deaf beef beef

It is clearly establishing a route to the e362 subnet.  I have linux box on the e300 subnet, it gets this RA message an sets up the route specified in the RA message as expected, but the Comcast Router appears to be unable to do so.

I think the Comcast device should be doing the same thing.  If it did so, it would not be using NS requests.

I've tried setting the prefix to /56 and /59 (for the route entry in the RA message) but that did not bear fruit either.

How can we get the Comcast Modem to respect the information in the RA message so that proper routing can be performed?

Thank you,

Good Morning!

I have a follow up post, but I think we've got a forum-bot erroneously marking it as private.

In it I show a tcpdump of the ping to google.com coming out of our LAN and the Comcast Modem attempting to delver the reply. 

It is sending out Neighbor Solicitation inquiries to find the IP address of the box sending the ping.  Obviously, being on the wrong subnet, it gets nothing so it tries again before it gives up.

I also show the Router Advertisement that is being injected into subnet the Cable Modem is attached to and in that RA is a RFC 4191 compliant 'route' specification that if the Cable Modem was paying attention would use to forward the ICMPv6 echo reply.

I learned something while setting this up, the Linux box I put on this network segment (along with the Cable Modem) also did not at first listen to the 'route' information embedded in the RA. I had to set the:

net.ipv6.conf.<interface name>.accept_ra_rt_info_max_plen=64

for the networking stack to utilize the 'route' information in the RA message.

It occurred to me this morning that the Cable Modem could very well have a similar setting. If our tech support sisters and brothers were game, perhaps we could talk someone into adjusting this setting for us?  You could do this on the command line as a non-persistent quick test via:

sysctl -w  net.ipv6.conf.<interface name>.accept_ra_rt_info_max_plen=64

and if it worked, we could then add the setting to /etc/sysctl.conf (or its equivalent) in the Cable Modem.

I think it would be that simple and we would have the ability to configure our networks in which way we need....