DHCPv6 PD oddity with client changing prefix size.

[Tim DeNike]

Running 4.3.5 in an ISP environment.  Delivering prefixes via DHCPv6-PD.

By default we give users a /64 but will allow them to request a /60 or /56.

Everything works fine with the /64s and /60s EXCEPT if a user changes prefix lengths.

IE:  User plugs in and enables DHCPv6, they get a /64.  They decide they want a /60 so change their prefix hint to /60 release/renew, they get the same /64 back again.

The only way to get them to acquire a /60 is to either manually remove the /64 lease from the leases file or wait out until the default-lease-time has expired.

Apparently when the client releases the prefix, it is still held for them so they can get it back.  No problem with that functionality.  Makes sense.  But if the client releases and requests a prefix that doesn't have a length that matches the previous lease then they should be allocated a prefix from the pool that does match based on the rules of "prefix-length-mode".

We do have "prefix-length-mode exact;" set.

Seems like a simple oversight/unintended side effect.

Thoughts?

Tim

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

[Simon Hobson]

Can't help with the problem, but an observation ...

Tim DeNike <[hidden email]> wrote:

> By default we give users a /64 but will allow them to request a /60 or /56.

Why not a /56 by default, and a /48 on request ?

There's an endless discussion over on the V6 Ops list about various things - and a common "discussion point' is whether to relax the /64 that's more or less hardcoded into several standards documents. One of the arguments against relaxation is that it imposes a minimum on ISPs who would otherwise start offering a /96, or a /120, or ... and we'd soon be back to users forced into using NAT.

And there is work in progress (eg to make home users secure by default - eg by separating the IoTat stuff from their main network) that will require multiple /64s.

Don't have a reference, but AIUI, anything less than /56 is "just wrong", and /48 is preferred as a default allocation.


But at least you are offering IPv6 - my ISP ran trials a few years ago and has since gone "very quiet" on their plans :-(

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

[Tim DeNike]

#1 reason.  We had a couple of consumer routers that wouldn't take
anything other than a /64.  I honestly can't remember what brand they
were.


Sent from my iPhone

> On Aug 15, 2017, at 3:08 AM, Simon Hobson <[hidden email]> wrote:
>
> Can't help with the problem, but an observation ...
>
> Tim DeNike <[hidden email]> wrote:
>
>> By default we give users a /64 but will allow them to request a /60 or /56.
>
> Why not a /56 by default, and a /48 on request ?
>
> There's an endless discussion over on the V6 Ops list about various things - and a common "discussion point' is whether to relax the /64 that's more or less hardcoded into several standards documents. One of the arguments against relaxation is that it imposes a minimum on ISPs who would otherwise start offering a /96, or a /120, or ... and we'd soon be back to users forced into using NAT.
>
> And there is work in progress (eg to make home users secure by default - eg by separating the IoTat stuff from their main network) that will require multiple /64s.
>
> Don't have a reference, but AIUI, anything less than /56 is "just wrong", and /48 is preferred as a default allocation.
>
>
> But at least you are offering IPv6 - my ISP ran trials a few years ago and has since gone "very quiet" on their plans :-(
>
> _______________________________________________
> 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

[Simon Hobson]

Tim DeNike <[hidden email]> wrote:

> #1 reason.  We had a couple of consumer routers that wouldn't take
> anything other than a /64.  I honestly can't remember what brand they
> were.

Well I suppose that's not too bad a reason.


I suspect that they'd be interested in feedback over at v6ops list <[hidden email]>, https://www.ietf.org/mailman/listinfo/v6ops - especially if you can name and shame the manufacturer responsible. I know there's recently been some work on a standards (or could be BCP) document specifying what consumer routers should do/be capable of.
I think "router unable to accept other than a single /64 prefix" could be considered a hindrance to IPv6 takeup.

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

[Thomas Markwalder]

Hello Tim:

I retested your scenario with 4.3.6 which we released on 7/31.  While it does contain a correction for one issue with prefix delegation it does not address your scenario which I tested as:

1. Configured a server to have two PD pools in the same subnet, one /64 and the other /60,  prefix-length-mode = exact
2. Solicits from the same client with prefix length hints of /64 and /60 , are offered leases of /64 and /60, respectively
(confirming hints are being honored as expected)
3. Client solicits a /64, and accepts the offered /64 PD lease
4. Client releases /64 PD lease
5. Client solicits a /60
6. Server offers prior /64 PD lease

(Note prefix value for all solicits was "::")

If you would be so kind as to open a bug for this, we should be able to work it into 4.4.0 which is slated for January '18.

We are also planning to change the default prefix-length-mode to "prefer" as this is more in line with RFC 8168, as well
as providing a less-stringent default user experience.

FYI, the issue we did correct in 4.3.6 was this:

"- The server nows checks both the address and length of a prefix delegation
  when attempting to match it to a prefix pool.  This ensures the server
  responds properly when pool configurations change such that once valid,
  "in-pool" delegations are now treated as being invalid.  During lease
  file loading at startup, the server will discard any PD leases that
  are deemed "out-of-pool" either by address or mis-matched prefix length.
  Clients seeking to renew or rebind such leases will get a response of
  No Binding in the case of the former, and the prefix delegation with
  lifetimes set to zero in the case of the latter. Thanks to Mark Nejedlo
  at TDS Telecom for reporting this issue.
  [ISC-Bugs #35378]"


Sincerely,

Thomas Markwalder
ISC Software Engineering





On 8/14/17 1:53 PM, Tim DeNike wrote:

Running 4.3.5 in an ISP environment.  Delivering prefixes via DHCPv6-PD.

By default we give users a /64 but will allow them to request a /60 or /56.

Everything works fine with the /64s and /60s EXCEPT if a user changes prefix lengths.

IE:  User plugs in and enables DHCPv6, they get a /64.  They decide they want a /60 so change their prefix hint to /60 release/renew, they get the same /64 back again.

The only way to get them to acquire a /60 is to either manually remove the /64 lease from the leases file or wait out until the default-lease-time has expired.

Apparently when the client releases the prefix, it is still held for them so they can get it back.  No problem with that functionality.  Makes sense.  But if the client releases and requests a prefix that doesn't have a length that matches the previous lease then they should be allocated a prefix from the pool that does match based on the rules of "prefix-length-mode".

We do have "prefix-length-mode exact;" set.

Seems like a simple oversight/unintended side effect.

Thoughts?

Tim

_______________________________________________
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

[Tim DeNike]

Awesome.  Will do!

On Tue, Aug 15, 2017 at 7:36 AM, Thomas Markwalder <[hidden email]> wrote:

Hello Tim:

I retested your scenario with 4.3.6 which we released on 7/31.  While it does contain a correction for one issue with prefix delegation it does not address your scenario which I tested as:

1. Configured a server to have two PD pools in the same subnet, one /64 and the other /60,  prefix-length-mode = exact
2. Solicits from the same client with prefix length hints of /64 and /60 , are offered leases of /64 and /60, respectively
(confirming hints are being honored as expected)
3. Client solicits a /64, and accepts the offered /64 PD lease
4. Client releases /64 PD lease
5. Client solicits a /60
6. Server offers prior /64 PD lease

(Note prefix value for all solicits was "::")

If you would be so kind as to open a bug for this, we should be able to work it into 4.4.0 which is slated for January '18.

We are also planning to change the default prefix-length-mode to "prefer" as this is more in line with RFC 8168, as well
as providing a less-stringent default user experience.

FYI, the issue we did correct in 4.3.6 was this:

"- The server nows checks both the address and length of a prefix delegation
  when attempting to match it to a prefix pool.  This ensures the server
  responds properly when pool configurations change such that once valid,
  "in-pool" delegations are now treated as being invalid.  During lease
  file loading at startup, the server will discard any PD leases that
  are deemed "out-of-pool" either by address or mis-matched prefix length.
  Clients seeking to renew or rebind such leases will get a response of
  No Binding in the case of the former, and the prefix delegation with
  lifetimes set to zero in the case of the latter. Thanks to Mark Nejedlo
  at TDS Telecom for reporting this issue.
  [ISC-Bugs #35378]"


Sincerely,

Thomas Markwalder
ISC Software Engineering

On 8/14/17 1:53 PM, Tim DeNike wrote:

Running 4.3.5 in an ISP environment.  Delivering prefixes via DHCPv6-PD.

By default we give users a /64 but will allow them to request a /60 or /56.

Everything works fine with the /64s and /60s EXCEPT if a user changes prefix lengths.

IE:  User plugs in and enables DHCPv6, they get a /64.  They decide they want a /60 so change their prefix hint to /60 release/renew, they get the same /64 back again.

The only way to get them to acquire a /60 is to either manually remove the /64 lease from the leases file or wait out until the default-lease-time has expired.

Apparently when the client releases the prefix, it is still held for them so they can get it back.  No problem with that functionality.  Makes sense.  But if the client releases and requests a prefix that doesn't have a length that matches the previous lease then they should be allocated a prefix from the pool that does match based on the rules of "prefix-length-mode".

We do have "prefix-length-mode exact;" set.

Seems like a simple oversight/unintended side effect.

Thoughts?

Tim

_______________________________________________
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

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

[David Farmer]

On Tue, Aug 15, 2017 at 4:47 AM, Simon Hobson <[hidden email]> wrote:

Tim DeNike <[hidden email]> wrote:

> #1 reason.  We had a couple of consumer routers that wouldn't take
> anything other than a /64.  I honestly can't remember what brand they
> were.

Well I suppose that's not too bad a reason.


I suspect that they'd be interested in feedback over at v6ops list <[hidden email]>, https://www.ietf.org/mailman/listinfo/v6ops - especially if you can name and shame the manufacturer responsible. I know there's recently been some work on a standards (or could be BCP) document specifying what consumer routers should do/be capable of.
I think "router unable to accept other than a single /64 prefix" could be considered a hindrance to IPv6 takeup.

I've heard this reason before, and I have no reason to believe it not true.  However, it is now time to name and shame, otherwise this will become lore. And, once this becomes lore it will be difficult to convince others that you don't have to default to a single /64. Therefore, we are now at the point that we cannot accept this excuse without naming the vendor.  Without the name of the vendor there is no way to apply pressure to fix the issue and it only serves to reinforces the idea that you have to default to /64 for DHCPv6 PD, without making it possible to fix the issue.

So please name and shame, we can no longer tolerate CPE that only accept a single /64 from DHCPv6 PD.

Thanks.

--

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

[Tim DeNike]

I honestly don't remember.. It was something off the wall and happened over a year ago.  Not your typical netgear/linksys/dlink consumer router.

If I come across it again, ill keep it in mind and let you know.

Im still not pro /48 per user.. Flexible availability of larger subnets for sure.  Primary concern is compatibility, not giving everyone 65000 subnets by default.  98% of our users that have IPv6 probably don't even realize they have it.  Thats the way it should be.  The transition should be transparent to the sheep.  Literally 0.04% of our user base has requested longer than a /64.

The default should be what works in every case, not what wed like to see in a perfect world.  The world is hardly perfect.  The last thing we need to do is have help desk arguing with customers about how their $42 dollar no-brand router sucks and they are stupid for getting it.

 

On Tue, Aug 15, 2017 at 10:42 AM, David Farmer <[hidden email]> wrote:

On Tue, Aug 15, 2017 at 4:47 AM, Simon Hobson <[hidden email]> wrote:

Tim DeNike <[hidden email]> wrote:

> #1 reason.  We had a couple of consumer routers that wouldn't take
> anything other than a /64.  I honestly can't remember what brand they
> were.

Well I suppose that's not too bad a reason.


I suspect that they'd be interested in feedback over at v6ops list <[hidden email]>, https://www.ietf.org/mailman/listinfo/v6ops - especially if you can name and shame the manufacturer responsible. I know there's recently been some work on a standards (or could be BCP) document specifying what consumer routers should do/be capable of.
I think "router unable to accept other than a single /64 prefix" could be considered a hindrance to IPv6 takeup.

I've heard this reason before, and I have no reason to believe it not true.  However, it is now time to name and shame, otherwise this will become lore. And, once this becomes lore it will be difficult to convince others that you don't have to default to a single /64. Therefore, we are now at the point that we cannot accept this excuse without naming the vendor.  Without the name of the vendor there is no way to apply pressure to fix the issue and it only serves to reinforces the idea that you have to default to /64 for DHCPv6 PD, without making it possible to fix the issue.

So please name and shame, we can no longer tolerate CPE that only accept a single /64 from DHCPv6 PD.

Thanks.

--

_______________________________________________
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