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

    Receiving /59 PD results in tracking interfaces using /63

    Scheduled Pinned Locked Moved IPv6
    29 Posts 6 Posters 2.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.
    • JKnottJ
      JKnott @slykens
      last edited by

      @slykens

      1. I see the /60 solicit
      2. I see the /59 offer
      3. I see the /59 request
      4. I see the /59 provided

      So, Comcast is giving a /59 when a /60 is requested, but pfsense then accepts it. I have no idea why pfsense is messing up a prefix that is accepted, but you should check with Comcast about why they're providing a /59, when a /60 is requested.

      PfSense running on Qotom mini PC
      i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
      UniFi AC-Lite access point

      I haven't lost my mind. It's around here...somewhere...

      johnpozJ S 2 Replies Last reply Reply Quote 0
      • johnpozJ
        johnpoz LAYER 8 Global Moderator @JKnott
        last edited by johnpoz

        @jknott said in Receiving /59 PD results in tracking interfaces using /63:

        I have no idea why pfsense is messing up a prefix that is accepted

        Yeah that is what I think should be fixed.. I hear ya the ISP is messed up.. But if you get /X as your prefix no matter if its what you asked for or not as far as size... I would hope pfsense should create your /64s from this - as long as its large enough to create your prefixes off of, etc..

        Its quite possible the coding of this is more involved than my noncoder brain thinks it is - but it doesn't seem like a optimal result setting /63s - which are not good..

        It very well could be a very low priority thing as well.. Since you would hope 999999/1000000 times the ISP would hand you the prefix you request..

        Maybe logging the mismatched prefix request vs assigning a bad prefix on the tracking interfaces would be better than assigning a /63 or /whatever that is not going to be good.

        An intelligent man is sometimes forced to be drunk to spend time with his fools
        If you get confused: Listen to the Music Play
        Please don't Chat/PM me for help, unless mod related
        SG-4860 24.11 | Lab VMs 2.8, 24.11

        S 1 Reply Last reply Reply Quote 0
        • S
          slykens @johnpoz
          last edited by

          @johnpoz said in Receiving /59 PD results in tracking interfaces using /63:

          It very well could be a very low priority thing as well.. Since you would hope 999999/1000000 times the ISP would hand you the prefix you request..

          I agree it’s not a dealbreaker but in this situation fixing pfSense is more agile than expecting Comcast to resolve their rectal cranial inversion quickly and likely benefits others who may have simply given up since IPv6 isn’t a requirement in many deployments. I’m very lucky to be working with a tech at Comcast who has not yet told me to pound sand.

          I also think it would be good if pfSense would respond to brain dead situations by doing the best it can - like you said, if there’s enough space to make /64s then do what it can. This isn’t a work around just for Comcast, per se, it would be a fix so pfSense would behave as expected.

          1 Reply Last reply Reply Quote 0
          • S
            slykens @JKnott
            last edited by

            @jknott said in Receiving /59 PD results in tracking interfaces using /63:

            @slykens

            1. I see the /60 solicit
            2. I see the /59 offer
            3. I see the /59 request
            4. I see the /59 provided

            So, Comcast is giving a /59 when a /60 is requested, but pfsense then accepts it. I have no idea why pfsense is messing up a prefix that is accepted, but you should check with Comcast about why they're providing a /59, when a /60 is requested.

            I don’t mean to be rude but I don’t think you read what I’ve posted. This is the second post in the thread from you where you either misunderstand what has been posted or you try to direct the conversation away from the issue posted about, in this case that pfSense mishandles assigning tracking interfaces /64s when it receives an “unexpected” delegation.

            To go down that road, yes you are correct that Comcast should handle it correctly, especially as a /60 is smaller than a /59, but Comcast has insisted to its customers for years that their modems work fine and when they finally get cornered have been telling customers to get bent. In my case the tech I am working with has taken it seriously and I (and other Comcast customers) can live with a /59 instead of a /60. PfSense properly handling the unexpected delegation would make the whole thing work more smoothly. I suggest this is important to fix as Comcast is a technology leader and their methods are likely to be replicated by other ISPs in the US and it’s not like it is a workaround only for Comcast - it’s fixing it so it behaves properly.

            DerelictD JKnottJ 2 Replies Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate @JKnott
              last edited by

              @jknott They send a /59. It's really stupid. So are they.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate @slykens
                last edited by

                @slykens Why should pfSense have to code around Comcast's long-term inability to provide the service you are paying for? Comcast Business IPv6 is a complete clown car.

                I have already explained the technical limitations surrounding this issue from the pfSense perspective. If you are supposed to get a /56 or a /60 and explicitly request a /56 or /60, and get a /59 (!) instead it is Comcast's provisioning that is broken - not the firewall. Should pfSense assume the technical debt in forking and maintaining their own dhcp6c because Comcast is hopelessly broken, continues to be broken for years, and tells you your third-party firewall is beyond our demarc and we can't help you with it despite multiple customers all providing the same data that Comcast's gear is at fault?

                Comcast doesn't care. Use an HE.net tunnel if Comcast is your only choice.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                S 1 Reply Last reply Reply Quote 0
                • JKnottJ
                  JKnott @slykens
                  last edited by

                  @slykens

                  If Comcast is anything like my ISP (Rogers), it has nothing to do with the modem. This is handled at the head end office, by the CMTS, which talks to the modem at the customer site. The modem, in bridge mode, as needed by pfsense for DHCPv6-PD to work, should be transparent. The alternative is for it to be in gateway mode, where a single /64 is provided it. In this case, you cannot use another router beyond it, to distribute a prefix.

                  The hard part may be getting the right people to work on the problem. A couple of years ago, I had a problem and was even able to identify the failing CMTS by host name. Even though both tier two support and a senior tech could see the problem was back at the head end, the appropriate people refused to work on the problem because I was running my own router (pfsense), ignoring the fact it was also happening to my next door neighbour, who was using the modem in gateway mode. It was only after the senior tech took his modem to the head end and tried it with 4 different CMTS, with it failing only on the one I was connected to, did those guys get off their butt to fix their problem.

                  Bottom line, Comcast should not be providing a /59, when a /60 is requested and that leaves the issue of pfsense not properly handling a prefix that it was given, even if incorrectly.

                  Incidentally, I have done work inside my ISP's offices in a few cities, though not the one I'm connected to and on equipment connected to the CMTS.

                  PfSense running on Qotom mini PC
                  i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                  UniFi AC-Lite access point

                  I haven't lost my mind. It's around here...somewhere...

                  S 2 Replies Last reply Reply Quote 0
                  • S
                    slykens @Derelict
                    last edited by

                    @derelict said in Receiving /59 PD results in tracking interfaces using /63:

                    Why should pfSense have to code around Comcast's long-term inability to provide the service you are paying for? Comcast Business IPv6 is a complete clown car.

                    Because it is not a fix "just for Comcast," even though they are the trouble in the instant scenario.

                    Expecting pfSense to behave logically is reasonable. Do you think it is reasonable that pfSense mishandles assigning /64s when it receives a larger delegation than expected? Do you believe this is the only potential or possible scenario where this could occur?

                    1 Reply Last reply Reply Quote 0
                    • MikeV7896M
                      MikeV7896
                      last edited by

                      Comcast or not, this is not the first time I’ve seen pfSense’s inability to handle a prefix size different from what has been requested. It really should be fixed, if for no reason than to provide a better user experience.

                      Does it require forking dhcpd just for pfSense? I would be surprised if it needed that drastic of a measure. But I’m not a developer, so I don’t know.

                      The S in IOT stands for Security

                      JKnottJ 1 Reply Last reply Reply Quote 1
                      • S
                        slykens @JKnott
                        last edited by

                        @jknott said in Receiving /59 PD results in tracking interfaces using /63:

                        Bottom line, Comcast should not be providing a /59, when a /60 is requested and that leaves the issue of pfsense not properly handling a prefix that it was given, even if incorrectly.

                        I absolutely agree.

                        I also believe, however, it is reasonable to expect pfSense to properly handle what it does get as long as it can reasonable meet the need - in this case a /59 in place of a /60 obviously exceeds the need.

                        DerelictD 1 Reply Last reply Reply Quote 0
                        • JKnottJ
                          JKnott @MikeV7896
                          last edited by

                          @virgiliomi

                          My take on this is if there actually is a problem within pfsense, then it's in the FreeBSD it's based on and any such problem and possible fix should be sent upstream.

                          PfSense running on Qotom mini PC
                          i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                          UniFi AC-Lite access point

                          I haven't lost my mind. It's around here...somewhere...

                          1 Reply Last reply Reply Quote 0
                          • S
                            slykens @JKnott
                            last edited by slykens

                            @jknott said in Receiving /59 PD results in tracking interfaces using /63:

                            If Comcast is anything like my ISP (Rogers), it has nothing to do with the modem. This is handled at the head end office, by the CMTS, which talks to the modem at the customer site. The modem, in bridge mode, as needed by pfsense for DHCPv6-PD to work, should be transparent. The alternative is for it to be in gateway mode, where a single /64 is provided it. In this case, you cannot use another router beyond it, to distribute a prefix.

                            Comcast's business offering in regards to IPv6 is a mess as others here have astutely pointed out.

                            If you have static IPv4 service, you must use one of their modems. They use some flavor of RIP on the cable side to route your block to you and a "consumer" modem, like an SB8200, apparently won't do what they want. Again, if I was fully dynamic, both IPv4 and IPv6, as I am at my home this entire situation would not even have come up and would be handled upstream as you suggest.

                            The modem Comcast provides doesn't operate in bridge mode when static IPv4 is involved. It is the gateway on my /29 in IPv4. Comcast assigns the modem a /56, then modem assigns a /64 to its LAN interface, and the modem is responsible for handling the rest of it on its LAN interface side. In the instant scenario, I desire to ask it for a /60 but it will only give me a /59 - that's a limitation in the modem firmware as the PD request never goes beyond the modem as it has a /56 to give me address space out of. Now, I have configured pfSense to ask for the /59 and it properly handles assigning /64s internally but there's another problem in Comcast's modem where that traffic is being dropped by the modem - Comcast has told me this much - so I'm still waiting for them to suss that but expect everything to work happily once they do.

                            I suspect if I paid for a metro E delivered service I could have things done very differently but 200 Mbps DOCSIS is $99/mo whilst I suspect the ethernet service would start at $1000 and go up from there. Yes, I know, you get what you pay for. :)

                            1 Reply Last reply Reply Quote 0
                            • DerelictD
                              Derelict LAYER 8 Netgate @slykens
                              last edited by

                              @slykens Pull requests will be evaluated for appropriateness.

                              Chattanooga, Tennessee, USA
                              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                              Do Not Chat For Help! NO_WAN_EGRESS(TM)

                              1 Reply Last reply Reply Quote 0
                              • Bob.DigB
                                Bob.Dig LAYER 8
                                last edited by Bob.Dig

                                In the end, pfSense handling of IPv6 isn't ideal, for example not showing what the isp is providing. The router (with modem) I had to buy for my new dsl line shows this and even can delegate prefixes to pfSense. You got what you paid for, I guess.

                                1 Reply Last reply Reply Quote 0
                                • MikeV7896M
                                  MikeV7896
                                  last edited by MikeV7896

                                  Hmm... look... another ISP (in Germany this time) with the same issue. I guess Comcast isn't the only one broken. Can this be looked into now to see where the problem lies as far as pfSense's handling of prefix size received being different from prefix size requested?

                                  https://forum.netgate.com/topic/159463/ipv6-not-working-wan-and-lan-interface-getting-an-ip-adress-not-any-client

                                  The S in IOT stands for Security

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