Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 1 reply
  • Subscribers 0 subscribers
  • Views 1337 views
  • Users 0 members are here
Options
Suggested

IPv6 Broken in 9.3

sfurey
IPv6 seems to be pretty broken in 9.3

This is more for devs to read and fix rather than user interaction.

Prior to 9.3 you could either choose Prefix Assignments or DHCPv6. This was handy because Prefix Assignments on the UTM require a /64 prefix. This is another gripe as the RFC for Prefix Assignments states 

3.1.  Number and Length of Delegated Prefixes



   The prefix delegation mechanism should allow for delegation of

   prefixes of lengths between /48 and /64, inclusively.  Other lengths

   should also be supported.  The mechanism should allow for delegation

   of more than one prefix to the customer.


So that should be changed regardless.

Anyways...in 9.3 this was changed so that DHCPv6 now requires Prefix Assignments to be turned on but if you have an ISP like Comcast that only gives you 1 /64 for your internal LAN then you are forced to subnet that for multiple networks.

The other part of IPv6 that seems broken, I tested minimally...

Prior to 9.3 you could either NAT your LAN IPv6 range to your WAN IPv6 address or just come directly from the LAN IPv6 range. Once I upgrade to 9.3 I was not able to access the internet via IPv6 until I added a NAT rule for my IPv6 network which sort of defeats the purpose of IPv6.

I have rolled back to 9.209 in the meantime and everything is working again.
  • 0
    Nah. First, nothing has been reduced in regard of possibilities. In fact, it has even been extended a little.

    You're mixing up "DHCPv6 Prefix Delegation" and "Router Advertisements". DHCPv6 PD the UTM only supports in client mode, so it can request prefixes from ISP, but not provide prefixes itself via DHCPv6 PD. And the latter (Router Advertisements) are /64 only which is exactly what they've been designed for. No changes here.

    The reason why Comcast doesn't work properly for you is due to a dhclient limitation from the ISC DHCP distribution. It doesn't support a custom prefix length hint to request for, which in turn Comcast needs to assign you sth. bigger than a /64, e.g. /48. They auto-assign only a /64 if no prefix length hint was given in the DHCPv6 request. Since dhclient never supported that (and UTM uses dhclient), it never worked before.

    So here is what actually changed in v9.3 regarding IPv6:

    * Application control support
    * DynDNS support (DYN & FreeDNS)
    * DHCPv6 "rapid commit" support
    * Router advertisements are now more flexible regarding the optional DHCPv6 flags. For example you can now use RAs from UTM but an external DHCPv6 server in your LAN, as the 'managed' or 'other config' flags don't necessarily auto-start the builtin DHCPv6 server. Unfortunately, Sophos calls "Router Advertisements" in UTM "Prefix Advertisements", they really should rephrase this.

    Thinking of these changes, could you please post back if that resolved your "issues"? Your UTM should behave exactly as before 9.3x.

    If you only get a /64 from Comcast, it's normal that you have to NAT this for your LAN because /64 cannot be subnetted any further.

    If you're interested in my home setup: ISP (KabelBW) -> /56 via DHCPv6 PD -> Fritz!Box 6360 Cable (CPE from ISP) -> /62 via DHCPv6 PD -> UTM -> (Internal: /64 via RA | Guests: Another /64 via RA, both also using DHCPv6 for adresses & DNS). NAT only for IPv4.
Unfiltered HTML