PD broken in v4.3.2? prefix6 start prefix is outside the subnet

[Chris Buechler]

DHCPv6 PD configurations that worked in 4.3.1, 4.2.x, and earlier
versions have stopped working in 4.3.2. For instance, this
configuration will no longer work.
https://kb.isc.org/article/AA-01093/0/Adding-class-support-for-DHCPv6-in-ISC-DHCP-4.3.html

every instance of 'prefix6' I found in this list's archives will no
longer work, examples all over the Internet like this no longer work.
http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-isc-dhcp.html

You end up getting "prefix6 start prefix is outside the subnet".

That's a result of this change noted in the release notes:

- Added checks in range6 and prefix6 statement parsing to ensure addresses
  are within the declared subnet. Thanks to Jiri Popelka at Red Hat for the
  bug report and patch.
  [ISC-Bugs #32453]
  [ISC-Bugs #17766]
  [ISC-Bugs #18510]
  [ISC-Bugs #23698]
  [ISC-Bugs #28883]


range6 I can understand. prefix6 seems to be a mistake though. Of
course it's outside the subnet, that's the nature of PD. There has
never been a requirement previously for prefix6 to be within the
declared subnet, and it worked fine. Now I can't find a conf file
anywhere that actually works with PD, across a variety of
circumstances that worked on 4.3.1 and earlier.

Is there something I'm missing here, or is PD actually broken?

Thanks!
Chris
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Shawn Routhier]

> On Jul 14, 2015, at 2:34 PM, Chris Buechler <[hidden email]> wrote:
>
> DHCPv6 PD configurations that worked in 4.3.1, 4.2.x, and earlier
> versions have stopped working in 4.3.2. For instance, this
> configuration will no longer work.
> https://kb.isc.org/article/AA-01093/0/Adding-class-support-for-DHCPv6-in-ISC-DHCP-4.3.html
>
> every instance of 'prefix6' I found in this list's archives will no
> longer work, examples all over the Internet like this no longer work.
> http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO/hints-daemons-isc-dhcp.html
>
> You end up getting "prefix6 start prefix is outside the subnet".
>
> That's a result of this change noted in the release notes:
>
> - Added checks in range6 and prefix6 statement parsing to ensure addresses
>  are within the declared subnet. Thanks to Jiri Popelka at Red Hat for the
>  bug report and patch.
>  [ISC-Bugs #32453]
>  [ISC-Bugs #17766]
>  [ISC-Bugs #18510]
>  [ISC-Bugs #23698]
>  [ISC-Bugs #28883]
>
>
> range6 I can understand. prefix6 seems to be a mistake though. Of
> course it's outside the subnet, that's the nature of PD. There has
> never been a requirement previously for prefix6 to be within the
> declared subnet, and it worked fine. Now I can't find a conf file
> anywhere that actually works with PD, across a variety of
> circumstances that worked on 4.3.1 and earlier.
>
> Is there something I'm missing here, or is PD actually broken?

We did make a change to restrict prefix6 to be within the subnet.
We are re-consdiering this change and would be interested in hearing
peoples comments.  Note that we are in the process of wrapping up
the current work on the releases so comments should be sent to the
list soon.

The argument for requiring the PD to be within
the subnet is that the subnet describes the topology of the network
and that it should map the routing of the network.  So to get to
a PD one would route to the given subnet.  

However I do think you are confused about the configuration file
showing class support from the KB article.  I have tried the three
configuration files in that kb article and all of them seem to work
correctly for me with the prefixes being within the subnet.  

The second example you give would appear to have issues though
they could be fixed by changing the subnet length from 64 to 56.

>
> Thanks!
> Chris
> _______________________________________________

regards,
Shawn

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Christian Kratzer]

Hi,

On Tue, 14 Jul 2015, Shawn Routhier wrote:
<snipp/>

> We did make a change to restrict prefix6 to be within the subnet.
> We are re-consdiering this change and would be interested in hearing
> peoples comments.  Note that we are in the process of wrapping up
> the current work on the releases so comments should be sent to the
> list soon.
>
> The argument for requiring the PD to be within
> the subnet is that the subnet describes the topology of the network
> and that it should map the routing of the network.  So to get to
> a PD one would route to the given subnet.

a couple of quick points on this:

1. this would require one to enlargeng the access network to emcompass
the whole pool of prefixes one wishes to delegate. This would definetely
be considered a broken design.

2. Just having the network large enough would still only route towards
the net.  This would not help with getting the ultimate next hop for the
assigned prefix resolved.

3. ipv6 relay agents on routers that support PD sniff the traffic and
transparently add the route to the delegated prefix to the correct next hop.


Such a change would definetely be broken and would have to be backed out.

I have not researched the actual facts myself yet.  Just judginge from
the description in the previous postings.


> However I do think you are confused about the configuration file
> showing class support from the KB article.  I have tried the three
> configuration files in that kb article and all of them seem to work
> correctly for me with the prefixes being within the subnet.
>
> The second example you give would appear to have issues though
> they could be fixed by changing the subnet length from 64 to 56.


Greeetings
Christian

--
Christian Kratzer                   CK Software GmbH
Email:   [hidden email]               Wildberger Weg 24/2
Phone:   [phone] - 0       D-71126 Gaeufelden
Fax:     [phone] - 9       HRB 245288, Amtsgericht Stuttgart
Mobile:  [phone]           Geschaeftsfuehrer: Christian Kratzer
Web:     http://www.cksoft.de/
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Chris Buechler]

On Wed, Jul 15, 2015 at 3:59 AM, Christian Kratzer <[hidden email]> wrote:
>
> a couple of quick points on this:
>
> 1. this would require one to enlargeng the access network to emcompass
> the whole pool of prefixes one wishes to delegate. This would definetely
> be considered a broken design.
>

Yes, especially considering there's no reason the PD subnet needs to
be even close to the interface's subnet. As things stand now after
that change, in some circumstances you'd need a subnet6 2000::/3 or
close to it for PD to work.


> 2. Just having the network large enough would still only route towards
> the net.  This would not help with getting the ultimate next hop for the
> assigned prefix resolved.
>
> 3. ipv6 relay agents on routers that support PD sniff the traffic and
> transparently add the route to the delegated prefix to the correct next hop.
>
> Such a change would definetely be broken and would have to be backed out.
>

Yes, agree.


On Wed, Jul 15, 2015 at 12:17 AM, Shawn Routhier <[hidden email]> wrote:
>
> However I do think you are confused about the configuration file
> showing class support from the KB article.  I have tried the three
> configuration files in that kb article and all of them seem to work
> correctly for me with the prefixes being within the subnet.
>

Correct, the issue is where they're outside the subnet, sorry I wasn't
clear on that part.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Jim Pingle]

[Apologies for breaking threading]
On Wed Jul 15, 2015 at 12:23 PM EDT 2015, Chris Buechler cmb at
pfsense.org wrote:

> On Wed, Jul 15, 2015 at 3:59 AM, Christian Kratzer <ck-lists at cksoft.de> wrote:
>>
>> a couple of quick points on this:
>>
>> 1. this would require one to enlargeng the access network to emcompass
>> the whole pool of prefixes one wishes to delegate. This would definetely
>> be considered a broken design.
>>
>
> Yes, especially considering there's no reason the PD subnet needs to
> be even close to the interface's subnet. As things stand now after
> that change, in some circumstances you'd need a subnet6 2000::/3 or
> close to it for PD to work.

I concur, the relationship implied by the new check is an invalid
assumption. The subnet and the prefix for delegation need not be related
at all, so the check should be removed.

In a common example, consider this:

A tunnel from Hurricane Electric with a /64 for the "LAN" and a routed
/48. The downstream devices get an address inside of the "LAN" /64 and
are delegated a block out of the /48 for their own use. Routes are added
dynamically for the delegated blocks. This scenario worked perfectly on
previous versions but broke after the last release.

>> 2. Just having the network large enough would still only route towards
>> the net.  This would not help with getting the ultimate next hop for the
>> assigned prefix resolved.
>>
>> 3. ipv6 relay agents on routers that support PD sniff the traffic and
>> transparently add the route to the delegated prefix to the correct next hop.
>>
>> Such a change would definetely be broken and would have to be backed out.
>>
>
> Yes, agree.

There is also a related check of the prefix size against the subnet
("network mask smaller than subnet mask"), which becomes irrelevant with
the other check removed. Since the prefix is unrelated to the subnet, it
does not matter if the mask is smaller. It's quite common to delegate
/60 chunks to clients even when the "LAN" (in the above example) is /64.

Jim
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Chris Buechler]

On Wed, Jul 15, 2015 at 5:01 PM, Jim Pingle <[hidden email]> wrote:
>
> There is also a related check of the prefix size against the subnet
> ("network mask smaller than subnet mask"), which becomes irrelevant with
> the other check removed. Since the prefix is unrelated to the subnet, it
> does not matter if the mask is smaller. It's quite common to delegate
> /60 chunks to clients even when the "LAN" (in the above example) is /64.
>

Yes, that check is invalid as well.

In pfSense, we patched our dhcpd (4.2.8) to remove those two checks,
and PD is back to working correctly, as it did previously. There are
many configurations where it's impractical at best to meet this
validation. Agree with Christian earlier in the thread, and Jim, this
is broken.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Frank Bulk]

Agreed with Christian and Jim.

Frank

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Chris Buechler
Sent: Wednesday, July 15, 2015 11:19 PM
To: Users of ISC DHCP <[hidden email]>
Subject: Re: PD broken in v4.3.2? prefix6 start prefix is outside the subnet

On Wed, Jul 15, 2015 at 5:01 PM, Jim Pingle <[hidden email]> wrote:
>
> There is also a related check of the prefix size against the subnet
> ("network mask smaller than subnet mask"), which becomes irrelevant with
> the other check removed. Since the prefix is unrelated to the subnet, it
> does not matter if the mask is smaller. It's quite common to delegate
> /60 chunks to clients even when the "LAN" (in the above example) is /64.
>

Yes, that check is invalid as well.

In pfSense, we patched our dhcpd (4.2.8) to remove those two checks,
and PD is back to working correctly, as it did previously. There are
many configurations where it's impractical at best to meet this
validation. Agree with Christian earlier in the thread, and Jim, this
is broken.
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users