Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPv6 Comcast not working - overlapping v6 prefix delegation subnets?

    Scheduled Pinned Locked Moved IPv6
    40 Posts 11 Posters 19.8k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • H
      hardtarget
      last edited by

      @razzfazz:

      Both replies are actually coming from one and the same server. Both have different IA_ADDR's, too, so I agree that this is most likely a leftover from a prior lease. I'd try just rebooting pfSense and power cycling the cable modem first before messing with the MAC.

      Rebooted the CM and pfSense, and I'm still seeing the same two replies (/64 preference 255, /60 preference 0).  I'd rather not change my MAC, since my IPv4 address is bound to it right now, so I will wait for a few days and see if the /64 lease will eventually expire and start assigning the /60.  Does anybody know roundabout how long the leases are for IPv6 prefixes on Comcast's network?

      1 Reply Last reply Reply Quote 0
      • R
        razzfazz
        last edited by

        @priller:

        Why would you say that?

        Yeah, I just saw that the source address is the same for both replies; my bad. I guess the CMTS serves as a DHCP relay, then?

        1 Reply Last reply Reply Quote 0
        • R
          razzfazz
          last edited by

          @Kyle:

          Does anybody know roundabout how long the leases are for IPv6 prefixes on Comcast's network?

          See the pltime and vltime (preferred and valid lease duration, in seconds); looks like the default is 4 days, and at the time of the capture the older lease had been active for about 20 minutes and counting.

          1 Reply Last reply Reply Quote 0
          • H
            hardtarget
            last edited by

            @razzfazz:

            See the pltime and vltime (preferred and valid lease duration, in seconds); looks like the default is 4 days, and at the time of the capture the older lease had been active for about 20 minutes and counting.

            Thanks razzfazz, I will keep ya'll posted over the next few days and let you know what happens.

            1 Reply Last reply Reply Quote 0
            • AhnHELA
              AhnHEL
              last edited by

              @Kyle:

              So I did the above (requesting a /60 prefix on the WAN, then starting with my LAN, I did prefix ID's of 1-4), but now I'm not getting any IPv6 addresses on any connected networks (or interfaces).  However, the WAN still has the /128 assigned to it.

              Highly interested in this thread as I am seeing similar behavior.  Requesting a /64 on TWC's Road Runner gives me a /128 for WAN and a /64 for the LAN and everything works as it should. DHCPv6 for WAN and Track Interface for LAN.

              But when I request a /60 I get a /128 for WAN and a /60 for my LAN, WIFI, AND OPT interfaces using prefix ID's of 1-3 respectively.  This looks awesome but no connected PCs get a IPv6 address and I get a 0/10 running the test at www.test-ipv6.com

              AhnHEL (Angel)

              1 Reply Last reply Reply Quote 0
              • R
                razzfazz
                last edited by

                Odd, I can request a /60 from Comcast just fine and I end up with different /64 prefixes (all subsets of the /60) on each internal interface, so it doesn't seem to be a general problem with the prefix delegation code. Do you get your v4 connectivity through PPPoE by any chance?

                1 Reply Last reply Reply Quote 0
                • AhnHELA
                  AhnHEL
                  last edited by

                  Yeah, might be something screwy with my ISP requesting anything larger than a /64 that it gives me a /60 on every interface.  IPv6 addresses all look good (no private IPv6 addreses) but its still not routing or handing out IPs

                  No PPPoE here, cable modem connection with native IPv6.

                  AhnHEL (Angel)

                  1 Reply Last reply Reply Quote 0
                  • R
                    razzfazz
                    last edited by

                    SLAAC doesn't work with anything but /64's, so I'm not surprised the clients wouldn't know what to do if you advertise a /60 to them.

                    1 Reply Last reply Reply Quote 0
                    • AhnHELA
                      AhnHEL
                      last edited by

                      This is with Track Interface though, or am I missing something?  I know quite a bit about networking but I'm still trying to grasp this IPv6 and its terminology.

                      AhnHEL (Angel)

                      1 Reply Last reply Reply Quote 0
                      • R
                        razzfazz
                        last edited by

                        Yeah, I don't understand why that seems to end up advertising the whole prefix on the internal interfaces for some; just pointing out that it's not unexpected that clients wouldn't be able to get an IPv6 address when that happens.

                        1 Reply Last reply Reply Quote 0
                        • AhnHELA
                          AhnHEL
                          last edited by

                          Reverted back to DHCP6 on WAN with a /64 Prefix Delegation Size, and Track Interface on LAN.

                          This is the only way I can get IPv6 to work albeit just on the LAN.  Any other method either doesnt give out IPv6 addresses or causes workstations to fail the IPv6 test sites.

                          AhnHEL (Angel)

                          1 Reply Last reply Reply Quote 0
                          • H
                            hardtarget
                            last edited by

                            @Kyle:

                            Thanks razzfazz, I will keep ya'll posted over the next few days and let you know what happens.

                            Okay, so I wanted to check and see if the lease times were decrementing for each of the prefix advertisements (/60 vs. /64) comparing the 10/4 capture to one from 10/6 (today).

                            • ipv6-comcast-20131004.cap (packets 38-40)

                            • /60 Prefix Advertisement (packet 39)

                            • Preference: 0

                            • Preferred lease time (pltime): 345600

                            • Valid lease time (vltime): 345600

                            • /64 Prefix Advertisement (packet 40)

                            • Preference: 255

                            • preferred lease time (pltime): 345385

                            • valid lease time (vltime): 345385

                            • ipv6-comcast-20131006.cap (packets 98-100)

                            • /60 Prefix Advertisement (packet 99)

                            • Preference: 0

                            • Preferred lease time (pltime): 345600

                            • Valid lease time (vltime): 345600

                            • /64 Prefix Advertisement (packet 100)

                            • Preference: 255

                            • preferred lease time (pltime): 174315

                            • valid lease time (vltime): 174315

                            So, it does look like the /64 lease will eventually expire in about 48 hours.  Hopefully that will trigger the /60 offer to take effect.

                            1 Reply Last reply Reply Quote 0
                            • H
                              hardtarget
                              last edited by

                              Okay, so it looks like my leases have expired, I am getting a new address on the WAN interface (/128), but still nothing on the backend.  I do see these error messages in the System Logs though:

                              
                              Oct 8 15:31:15 	dhcp6c[72315]: client6_recvadvert: XID mismatch
                              Oct 8 15:31:15 	dhcp6c[72315]: client6_recvadvert: XID mismatch
                              Oct 8 15:29:14 	dhcp6c[72315]: client6_recvadvert: XID mismatch
                              Oct 8 15:29:14 	dhcp6c[72315]: client6_recvadvert: XID mismatch
                              
                              

                              In this capture from today, I can see the pltime/vltime have reset in packets 70-72–the /60 offer is valid for 345600 with preference 00 and the /64 is valid for 329817 with preference 255.  To me, it seems like this is still broken, though I can't tell if it's Comcast handing out bad leases or pfSense not picking the right one--perhaps it's got something to do with the XID mismatch above as well?

                              1 Reply Last reply Reply Quote 0
                              • K
                                kolinger
                                last edited by

                                I've been struggling with the same problem as ahnhell for the last few days and finally got it working.  I'm on TWC also and was able to get it to work by selecting the send prefix hint option and setting the prefix size to 64.  I've verified that when I select 60 as the prefix size, I get a/56 which results in /60's for my LAN and dmz interfaces.  I checked and pfsense is setting the prefix as "::/64 infinity" in dhcp6c_wan.cfg.

                                Am I misunderstanding how this is supposed to be configured or is TWC's implementation wrong?

                                1 Reply Last reply Reply Quote 0
                                • R
                                  razzfazz
                                  last edited by

                                  It's just a hint, so at the end of the day, they can do whatever they want with it (including ignoring it completely); that said, that behavior does seem odd. What size prefix do they give you when you uncheck "send hint"?

                                  1 Reply Last reply Reply Quote 0
                                  • K
                                    kolinger
                                    last edited by

                                    So, I spoke too soon - that's what I get for trying to test from my iPhone.  But it does look like selecting a prefix of /56 will work.  I will do more testing to verify.

                                    If I don't send a hint I get a /64.

                                    Edit:  I've done further testing and verified that when I request a /56 that is what I receive.  So this config seems to work (at least with TWC.)

                                    I guess the problem is when pfSense is configured to request a /60 the sla-len in the pd options is set to 4.  But when a /56 is received instead of the expected /60 each interface is configured with a /60 and stateless autoconfig won't work with this.  Hope this helps someone else.

                                    1 Reply Last reply Reply Quote 0
                                    • H
                                      hardtarget
                                      last edited by

                                      @kolinger:

                                      Edit:  I've done further testing and verified that when I request a /56 that is what I receive.  So this config seems to work (at least with TWC.)

                                      I've tried sending the /56 as the hint, and it's still not working.  Haven't had a chance to look at a packet capture yet, but I may end up having to call Comcast, which isn't really my first choice, but I don't know what else to try.

                                      1 Reply Last reply Reply Quote 0
                                      • M
                                        mikeisfly
                                        last edited by

                                        Sorry guys just saw this post. I had posted about this weeks ago in another thread. This is only for Comcast as far as I know, but if you live in the north east right now the CMTS's are not setup to deal with a prefix any larger/smaller than /64. See http://forum.pfsense.org/index.php/topic,65724.15.html

                                        Below is a link if you private message the OP of the forum he can tell you if this feature is supported yet in your area. He will need the CMAC of your cable modem. DON'T POST YOUR CMAC IN THE PUBLIC.

                                        http://forums.comcast.com/t5/Home-Networking-Router-WiFi/IPv6-prefix-size-and-home-routing/td-p/1495933

                                        1 Reply Last reply Reply Quote 0
                                        • R
                                          razzfazz
                                          last edited by

                                          @Kyle:

                                          I've tried sending the /56 as the hint, and it's still not working.  Haven't had a chance to look at a packet capture yet, but I may end up having to call Comcast, which isn't really my first choice, but I don't know what else to try.

                                          Did you try changing the MAC address on the WAN interface?

                                          1 Reply Last reply Reply Quote 0
                                          • R
                                            razzfazz
                                            last edited by

                                            @Kyle:

                                            I've tried sending the /56 as the hint, and it's still not working.

                                            Also, this will definitely not work on Comcast; as far as I know, the shortest prefix they'll hand out is a /60.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.