Navigation

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

    LAN no longer receiving IPv6 address

    IPv6
    2
    7
    187
    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.
    • A
      anthonys last edited by

      I have had IPv6 working using a SG-1100 for several months (via an ADSL service with a modem in bridge mode).

      My service provider has just migrated me to a new service, and IPv6 has stopped working. pfSense WAN reports an IPv6 address, but the LAN, OPT, no longer. My service provider help desk says all is fine at their end.

      My provider's doco says they provide /56 prefix delegation, which is how pfsense WAN->DHCPv6 Prefix Delegation size is set (and was working prior to service migration). LAN etc set to track WAN.

      But in the dhcpv6 log file, I see:

      May 10 08:10:51 pfSense dhcp6c[85872]: create a prefix 2001:44b8:204f:116::/64 pltime=3600, vltime=7201
      May 10 08:10:51 pfSense dhcp6c[85872]: invalid prefix length 64 + 8 + 64
      May 10 08:10:51 pfSense dhcp6c[85872]: invalid prefix length 64 + 8 + 64
      May 10 08:10:51 pfSense dhcp6c[85872]: invalid prefix length 64 + 8 + 64

      I'm assuming the "invalid prefix" indicates a problem. My question: A + B + C (i.e., 64 + 8 + 64), what do the values A, B and C mean - hoping one of these values points in towards the problem.

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

        @anthonys

        Capture the DHCPv6 packets and examine them in Wireshark. I had a problem with IPv6 with my ISP last year and Wireshark identified the failing system at my ISP. In the Advertise and Reply XID frames, you should find the prefix length. For a /56, it should be 56 and the prefix should end with 00::, which indicates the assigned prefix will fix within 56 bits. I see yours ends in 16, which is too long for a valid assigned /56 prefix. I suspect that's the cause of the "8".

        You may be able to capture the packets by configuring Packet Capture to capture ICMP6 on the WAN interface. Then disconnect & reconnect the WAN cable, which should trigger the DHCP sequence. You can then download the packets for inspection in Wireshark.

        Here's an example of what you're looking for:

        IA Prefix
        Option: IA Prefix (26)
        Length: 25
        Value: 00026e1900090599382607fea84c800b0000000000000000…
        Preferred lifetime: 159257
        Valid lifetime: 591257
        Prefix length: 56
        Prefix address: 2607:fea8:4c80:b00::

        BTW, here's the capture info which told me about the failed system at my ISP:

        Identity Association for Prefix Delegation
        Option: Identity Association for Prefix Delegation (25)
        Length: 72
        Value: 000000000000000000000000000d003800064e6f20707265...
        IAID: 00000000
        T1: 0
        T2: 0
        Status code
        Option: Status code (13)
        Length: 56
        Value: 00064e6f2070726566697820617661696c61626c65206f6e...
        Status Code: NoPrefixAvail (6) <-----
        Status Message: No prefix available on Link <-----
        'CMTS89.WLFDLE-BNDL1-GRP3' <-----

        So, Wireshark is a valuable tool when trying to resolve this sort of problem.

        1 Reply Last reply Reply Quote 0
        • A
          anthonys last edited by

          OK, tks, I'll need to familiarise myself with packet capture using pfSense first.

          In the mean time, I have experimented with other prefix lengths,
          with no change in behaviour except for setting it to /64. /64 seems to allow one of the 3 internal networks (LAN, which has IPv6 Prefix ID configured to 0) to get an IPv6 address, but not the other two.

          JKnott 2 Replies Last reply Reply Quote 0
          • JKnott
            JKnott @anthonys last edited by JKnott

            @anthonys

            Using Packet Capture is fairly easy. You just select the interface and what protocol you want to capture. Since you're looking for ICMP6, you don't even have to choose between IPv4 & IPv6, as it's only on IPv6.

            I was also wondering about the prefix length. Try for a /60 and see what happens.

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

              @anthonys

              Also, what size prefix are you requesting? What does your ISP say they're providing. While you can request a longer prefix, you can't request a shorter one. So, if they provide a /60, you could request a /60 or /64, but not /56.

              A 1 Reply Last reply Reply Quote 0
              • A
                anthonys @JKnott last edited by

                @JKnott

                Having managed to get past my service provider's level 1 help desk, and work with a network engineer, my problem has been confirmed as an infrastructure issue in the provider's network (they were offering /64, instead of /56).
                We tested fix with my account, and they are now deploying.

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

                  @anthonys

                  Glad to hear it. Yeah, ISPs sometimes cause their own problems, as the staff doesn't fully understand the differences between IPv4 and IPv6. When I had that problem last year, I had to educate both tier 2 support and the senior tech about what was actually happening. They knew the basics of IPv6, but not some of the finer points. At least you got relatively quick response from your ISP on this. It took me 3 months and a lot of work to get the people who should have fixed the problem to do anything. Since I had my own router, they refused to do anything, even though both the tier 2 guy and senior tech told them it was an ISP problem. What finally did the trick is the senior tech brought his own modem to my home and saw the problem. He then went to the head end and tried with 4 different CMTS. The failure only occurred with the one I was connected to. This was weeks after I provided the error (see above) to them.

                  BTW, I have decades of experience with telecommunications, computers and networks and so had the ability to work through this problem. A regular customer wouldn't have a hope of getting it resolved.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post

                  Products

                  • Platform Overview
                  • TNSR
                  • pfSense
                  • Appliances

                  Services

                  • Training
                  • Professional Services

                  Support

                  • Subscription Plans
                  • Contact Support
                  • Product Lifecycle
                  • Documentation

                  News

                  • Media Coverage
                  • Press
                  • Events

                  Resources

                  • Blog
                  • FAQ
                  • Find a Partner
                  • Resource Library
                  • Security Information

                  Company

                  • About Us
                  • Careers
                  • Partners
                  • Contact Us
                  • Legal
                  Our Mission

                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                  Subscribe to our Newsletter

                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                  © 2021 Rubicon Communications, LLC | Privacy Policy