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.
Parents
  • 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

  • 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.

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

     

Reply
  • 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.

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

     

Children
No Data