Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled)



  • I would really appreciate if someone could glance over these IPv6 settings and see if I've borked something. I'm still trying to wrap my head around the V6 concepts and terminology. DUID, IA-PD, IAID, RA, SLAAC, etc. "Everything works" but I am trying to grasp these concepts and want to make sure I'm doing things right.

    I have native IPv6 thru Spectrum/TimeWarner, and their modem is in bridge mode, attached to igb2 of my SG-4860 and named WAN2. The interface is getting assigned a routable ::/128 address via DHCP6.

    WAN2 DHCP6 settings look like this:
    dhcp1
    dhcp2

    Sniffing on that WAN2 I see that I am receiving RA's for 4 unique /64's, but I know you can specifically request a /56 (guide here) and so I've done that. It works, and I see in the logs that I'm being delegated a proper /56:
    56

    LAN is set to Track Interface.

    RA is enabled on the LAN and set to Assisted mode. This is what I have been told is most compatible with all types of devices (Windows, Android, iOS, Mac etc). Have not had any issues, although my Macs get two IPv6's, one "secured" and one "temporary". I assume the reason is one is via SLAAC and one is via DHCP6, although I haven't confirmed this and it doesn't seem to harm anything:

    $ ifconfig en0
    en0: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
      options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
      ether a8:20:66:xx:xx:xx
      inet6 fe80::1c29:99cb:9caf:943%en0 prefixlen 64 secured scopeid 0x7
      inet 192.168.20.xx netmask 0xffffff00 broadcast 192.168.20.255
      inet6 2604:xxxx:xxxx:xxxx:47f:38c8:68f3:cea prefixlen 64 autoconf secured
      inet6 2604:xxxx:xxxx:xxxx:918:6357:4542:60b prefixlen 64 autoconf temporary
      nd6 options=201<PERFORMNUD,DAD>
      media: autoselect (1000baseT <full-duplex,energy-efficient-ethernet>)
      status: active
    

    I have enabled DHCPv6 Server on LAN and the settings are like so:
    dhcp6-server

    Basically, I'm using the full ::-ffff:ffff:ffff:ffff range of the first /64 (prefix id=0). Then I am carving up my /56 and offering the "last 15" (:4410-:44f0) /60's to my "Lab" routers that might request it. I have tested this with another pfSense on my LAN behind the primary, and it successfully pulls a /60.

    I have a 10/10 on test-ipv6.com

    Is everything copacetic?



  • @luckman212 Don't forget to add firewall rules to allow ICMPv6. Ipv6 requires it to work.

    Here is my WAN rule for ICMP. LOCAL_SUBNETS is an Alias for my entire /56.
    0_1536867666381_wanipv6.PNG

    Also if you are subnetting to downstream router as it appears you are on your LAN interface, then you need a firewall rule to pass the entire range as a source address out. LAN Net includes only the local subnet.



  • Then try testing with http://ipv6-test.com/



  • @luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):

    RA is enabled on the LAN and set to Assisted mode. This is what I have been told is most compatible with all types of devices (Windows, Android, iOS, Mac etc). Have not had any issues, although my Macs get two IPv6's, one "secured" and one "temporary". I assume the reason is one is via SLAAC and one is via DHCP6, although I haven't confirmed this and it doesn't seem to harm anything:

    I don't have any Macs to compare to, but on a Windows PC, you will see 3 ip6s. One from DHCP, one from SLAAC, and a temporary one. The temporary one is for privacy and is the one that will be the source address from the PC and changes. So like I said, I don't know Macs, so I am not sure if they are set up to use DHCP or not. My iphones get three addresses like the PC's do if DHCP is working.

    Now that Windows 10 supports RDNSS I finally decided I didn't need DHCPv6 anymore, so I disabled it and now I use RA set to UnManaged.



  • @isaacfl Thanks for taking a look. Yes I have a rule to allow ICMP there, forgot to mention that. Mine is more permissive- just a blanket "allow all" if you will. Your setup looks more precise, might try to adapt to it.
    icmp



  • @luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):

    @isaacfl Thanks for taking a look. Yes I have a rule to allow ICMP there, forgot to mention that. Mine is more permissive- just a blanket "allow all" if you will. Your setup looks more precise, might try to adapt to it.
    icmp

    I think you are ok, just to let all icmp thru. I did that way, for a long time, but recently have been playing with restricting it more.

    If you enable logging of the icmp traffic you will see that there isn't that much. Nothing compared to all of the ipv4 port scanning on the WAN.



  • @luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):

    @isaacfl Thanks for taking a look. Yes I have a rule to allow ICMP there, forgot to mention that. Mine is more permissive- just a blanket "allow all" if you will.
    icmp

    I run the same way, and have for the past 10+ years of IPv6 use.



  • I've been doing some more experimenting, and it seems that when setting the LAN to "Track Interface(WAN)" that it gets assigned an IP in a /64 completely different from (and outside of) the range of the delegated /56. So, the entire /56 is available for downstream sub-routers. No need to omit the first Prefix-ID it seems. I have adjusted my settings and re-tested, everything still seems to work.

    Basically the only thing I changed was the Prefix Delegation Range now encompasses the full range of the /56:

    2604:2000:xxxx:4400:: --> 2604:2000:xxxx:44f0::

    Also, in mucking around I found it can be useful to call on the gen_subnetv6 and gen_subnetv6_max PHP functions from the developer shell (opt12). E.g.

    pfSense shell: require_once('util.inc');
    pfSense shell: $ip='2604:2000:ee00:ff00:284c:a2ff:a83b:334c';
    pfSense shell: $sn=67;
    pfSense shell: printf("%s%s\n", 'subnet base: ', gen_subnetv6($ip, $sn));
    pfSense shell: printf("%s%s\n", '        max: ', gen_subnetv6_max($ip, $sn));
    pfSense shell: exec
    subnet base: 2604:2000:ee00:ff00:2000::
            max: 2604:2000:ee00:ff00:3fff:ffff:ffff:ffff
    

  • LAYER 8 Netgate

    @luckman212 said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):

    when setting the LAN to "Track Interface(WAN)" that it gets assigned an IP in a /64 completely different from (and outside of) the range of the delegated /56

    That doesn't make a lot of sense. What routed subnet does LAN get assigned from?



  • @derelict said in Sanity check on my IPv6 settings (/56 PD + DHCP6 enabled):

    That doesn't make a lot of sense. What routed subnet does LAN get assigned from?

    Thanks @Derelict—I'm listing out my (partially masked) IPs below. To be honest, I'm not sure where the 2604:2000:f10f:ce00::/64 subnet is coming from. The primary router's LAN is set to Track Interface(WAN) but it seems like this IP is arriving via SLAAC or something. Not sure how to capture/trace that conversation (tcpdump?) but it's not showing up in radvdump.

    Here's what I have currently:

    (primary router)

    WAN:         2604:2000:ffc0:4:29da:xxxx:xxxx:xxxx/128
    LAN(track):  2604:2000:f10f:ce00:2xx:xxxx:xxxxx:e9da/64
    /56 via PD:  2604:2000:f120:4400::/56
                 DHCP6 server on this router is set to offer
                 16 /60s sliced up from the /56
    

    (sub-router)

    WAN:         2604:2000:f10f:ce00:2xx:xxxx:xxxx:55d0/64 (in LAN subnet of above)
    LAN(track):  2604:2000:f120:44f0:2xx:xxxx:xxxx:55cf/64 (in last /60 from primary router's DHCP6-PD pool)
    

    radvdump shows my Cable modem advertising these four /64s:

    2604:2000:700:4::/64
    2604:2000:400:4::/64
    2604:2000:c00:4::/64
    2604:2000:ffc0:4::/64  <-- the one chosen by my primary WAN (random?)
    

  • LAYER 8 Netgate

    SLAAC cannot delegate a prefix. A tracked interface cannot get a /64 from anything given by SLAAC. It has to be DHCP6.

    What does your ISP have to say about what they are provisioning there?



  • The ISP is Spectrum/TimeWarner. I'll call them tomorrow, but you don't get to talk to engineers, just call center people. Most of them can't even spell IPv6, much less tell you anything about it.

    Another odd thing, I rebooted pfSense and then checked the DHCP logs to see if I could confirm the /56 that was being handed out. I didn't see anything in the log at all for dhcp6 (yes, there was stuff in there before...) :

    # clog /var/log/dhcpd.log | grep dhcp6
    #      <------ ¯\_(ツ)_/¯
    

    radvdump shows that the /64s being offered there have valid lifetimes of infinity :

    prefix 2604:2000:ffc0:4::/64
    	{
    		AdvValidLifetime infinity; # (0xffffffff)
    		AdvPreferredLifetime infinity; # (0xffffffff)
    		AdvOnLink on;
    		AdvAutonomous off;
    		AdvRouterAddr off;
    	}; # End of prefix definition
    

    So maybe pfSense is caching this and just re-using it without triggering dhcp6c at all? I know it's not in config.xml so maybe on the filesystem somewhere? I have to look at the code to see if this is what's actually happening.

    I'll try to do some more packet captures as well.


Log in to reply