This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

IPv6 Delegated Prefix Size

Has anyone figured out how to get dhclient6 on a UTM9 box to request a larger delegated prefix?  I've been fiddling for hours and can't get anything other than a /64 from Comcast.  Found a post here from 2 years back but no solution.  



This thread was automatically locked due to age.
  • The /64 is possibly your link connection. Anyway why do you want more than a /64 unless you have multiple internal interfaces? Have you rung or looked at your comcast account to see if you are assigned a /56 or a /60 for your internal use?
    My AU ISP (internode) shows a /64 for the link and a delegated /56 for my use.

    Ian,

    home UTM 9.x running in ESXi 6 e3-1275v2

    AP55c and AP10 (courtesy Astaro)

    Three other UTMs, SUM and SFM in hibernation

    XG 15.x MR3 in hibernation

  • I do have multiple internal interfaces, hence the desire to request a /60 which, according to multiple postings in Comcast's forums, is supported if the router includes the PD hint in the DHCPv6 request.

    I've figured out that i can modify /var/chroot-dhcpc/etc/default.conf6 which is the template that the code uses to configure IPv6 on my external interface. I don't see how to change the command-line parameters being sent to dhclient6 yet. I've also found other people suggesting they can use versions of ISC dhclient6 with Comcast and pull a /60. The version of chclient6 on this machine is 4.3.0 which is pretty current.

    I've done some packet captures and I'm not seeing the IAPREFIX option in the solicitation. Wondering if anyone else has figured this out.

    PS: There's a feature request from 2013 somewhere on Sophos' site that suggests using another DHCPv6 package but that's a non-starter obviously for an end-user.
  • Any luck? i'm in a similar boat. I have multiple VLANs on my UTM and would like to hand out a PD to each of them and not just one. ATT can theoretically give me bigger subnets but the UTM seems convinced I only need a single /64. I just need ot know how to make the UTM ask for bigger
  • I asked on the ISC DHCP list and got nothing of use. One suggestion was to manually fiddle with the lease file but I never figured that out. Seems like it's not possible with this DHCP client. Sophos likely needs to look at using another.
  • as an alternative, what if the same /64 could be used on multiple lan ports? given each mac is unique and any IP concocted from the prefix will thus be unique, would that approach not suffice at least for some users?
  • You could do that but remember to subnet to less then /64. Also remember that the /64 is the standard smallest network size allocated except for some ISPs who allocate a /128 for your link.

    Ian,

    home UTM 9.x running in ESXi 6 e3-1275v2

    AP55c and AP10 (courtesy Astaro)

    Three other UTMs, SUM and SFM in hibernation

    XG 15.x MR3 in hibernation

  • Seems like this was addressed with dhclient version 4.4.1.  Sophos on 4.3.5.  Maybe on some future update we get lucky and the UI will add in an input for this.

  • It is possible to get a /60 PD.  Until the UI gets updated, this must be done manually.  UI should probably have the PD hint as an enable/disable check box, and when enabled, let you specify the hint size.

    The context for the copy/paste below is this;  UTM on it's own obtains a /64 PD when connected to my fiber isp's (att) gateway box. Goal was to get rid of the gateway entirely (which is a whole other ordeal) and obtain the /60 PD which is normally assigned to this gateway.   I did try other PD hint sizes. Regardless what was asked for, the isp only provided a /60.

     

    -------------------------------------
    from https://www.dslreports.com/forum/r32365875-

    Disabled wan interface, changed utm spoofed mac to bgw210's mac.

    Delete contents of /var/sec/chroot-dhcpc/var/db

    Connected that wretched arris box back up. Within a few minutes ipv6/global tab indicated the /64 delegated prefix. I didn't test for further connectivity as I wanted to see how easy it would be to get /60 back.

    Next, disabled wan again, changed back to cert's mac. Re-enabled interface, forced the wpa_supp handshake....Waited..waited.......waited some more. No renumbering. Wan interface ipv6 set at dhcp. Got tired of waiting, performed the following:

    *note, for anyone else reading, the WW, XX, YY, ZZ's are just place holders to hide the real values.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    utm:/var/sec/chroot-dhcpc/var/db # chroot  /var/sec/chroot-dhcpc /usr/sbin/dhclient6 -6 -P --prefix-len-hint 60 -d -D LLT -cf /etc/eth4.conf6 -lf /var/db/eth4_na.leases6 -pf /var/run/dhclient6_na_eth4.pid eth4
    Internet Systems Consortium DHCP Client 4.4.1
    Copyright 2004-2018 Internet Systems Consortium.
    All rights reserved.
    For info, please visit www.isc.org/.../
      
    Listening on Socket/eth4
    Sending on   Socket/eth4
    Created duid "\000\001\000\001$OV\XXXX\XXXX\XXXX\XXXX\XXXX".
    PRC: Soliciting for leases (INIT).
    XMT: Forming Solicit, 0 ms elapsed.
    XMT:  X-- IA_PD XX:XX:XX:XX
    XMT:  | X-- Request renew in  +3600
    XMT:  | X-- Request rebind in +5400
    XMT:  | | X-- Request prefix ::/60.
    XMT: Solicit on eth4, interval 1080ms.
    RCV: Advertise message on eth4 from fe80::216:YYYY:YYYY:YYYY.
    RCV:  X-- IA_PD XX:XX:XX:XX
    RCV:  | X-- starts 1555864159
    RCV:  | X-- t1 - renew  +1800
    RCV:  | X-- t2 - rebind +2880
    RCV:  | X-- [Options]
    RCV:  | | X-- IAPREFIX 2600:ZZZZ:ZZZZ:ZZZZ::/60
    RCV:  | | | X-- Preferred lifetime 3600.
    RCV:  | | | X-- Max lifetime 3600.
    RCV:  X-- Server ID: 00:03:00:01:00:WW:WW:WW:WW:WW
    RCV:  Advertisement recorded.
    PRC: Selecting best advertised lease.
    PRC: Considering best lease.
    PRC:  X-- Initial candidate 00:03:00:01:00:WW:WW:WW:WW:WW (s: 10103, p: 0).
    XMT: Forming Request, 0 ms elapsed.
    XMT:  X-- IA_PD XX:XX:XX:XX
    XMT:  | X-- Requested renew  +3600
    XMT:  | X-- Requested rebind +5400
    XMT:  | | X-- IAPREFIX 2600:ZZZZ:ZZZZ:ZZZZ::/60
    XMT:  | | | X-- Preferred lifetime +7200
    XMT:  | | | X-- Max lifetime +7500
    XMT:  V IA_PD appended.
    XMT: Request on eth4, interval 1040ms.
    RCV: Reply message on eth4 from fe80::216:YYYY:YYYY:YYYY.
    RCV:  X-- IA_PD XX:XX:XX:XX
    RCV:  | X-- starts 1555864160
    RCV:  | X-- t1 - renew  +1800
    RCV:  | X-- t2 - rebind +2880
    RCV:  | X-- [Options]
    RCV:  | | X-- IAPREFIX 2600:ZZZZ:ZZZZ:ZZZZ::/60
    RCV:  | | | X-- Preferred lifetime 3600.
    RCV:  | | | X-- Max lifetime 3600.
    RCV:  X-- Server ID: 00:03:00:01:00:WW:WW:WW:WW:WW
    PRC: Bound to lease 00:03:00:01:00:WW:WW:WW:WW:WW.
    connecting...
    connected.
    done.
    PRC: Renewal event scheduled in 1800 seconds, to run for 1080 seconds.
    PRC: Depreference scheduled in 3600 seconds.
    PRC: Expiration scheduled in 3600 seconds.


    Of course, wan still got the /128 ip because I haven't changed it back to static. Changed that back to the previous static ip and subnet to regain utm and clients ipv6 connectivity.

    Tl;dr It's possible to get a /60 PD by simply running the line above after a mac change. No need to wait for anything to expire. If the ipv6 lease file is deleted without releasing the ip (-r), then you will need to wait an hour.

    command line

    chroot /var/sec/chroot-dhcpc /usr/sbin/dhclient6 -6 -P --prefix-len-hint 60 -d -D LLT -cf /etc/eth4.conf6 -lf /var/db/eth4_na.leases6 -pf /var/run/dhclient6_na_eth4.pid eth4

    Including "-d" will cause it to run once then exit. Omit this to connect, the remain running background.

    Or change the wan mac spoof to something else. Delete the ipv6 lease file, rerun the dhclient6 command to obtain a new ipv6 pd. Rerun command with -r to release. Delete lease file. Change the wan mac spoof back, rerun dhclient6 command and you'll be back in business.

    The duid is in part associated with the wan mac. It's important to release the ipv6 before changing and delete the lease file or you will have to go through the above to get it going again.

    Conclusion: Why can't utm do this automatically. It seems to recognize the /64 PD as soon as it (utm) is connected to the bgw210. But when done directly, no such luck. Requires manual steps.

    ------------------------