| 2016-08-04 17:03:32 |
Dan Streetman |
bug |
|
|
added bug |
| 2016-08-04 17:04:34 |
Dan Streetman |
nominated for series |
|
Ubuntu Xenial |
|
| 2016-08-04 17:15:50 |
Dan Streetman |
attachment added |
|
lp1609898.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714179/+files/lp1609898.debdiff |
|
| 2016-08-04 17:32:22 |
Dan Streetman |
nominated for series |
|
Ubuntu Trusty |
|
| 2016-08-04 17:32:22 |
Dan Streetman |
nominated for series |
|
Ubuntu Precise |
|
| 2016-08-04 17:32:58 |
Dan Streetman |
attachment added |
|
lp1609898-precise.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714181/+files/lp1609898-precise.debdiff |
|
| 2016-08-04 17:33:17 |
Dan Streetman |
attachment added |
|
lp1609898-trusty.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714182/+files/lp1609898-trusty.debdiff |
|
| 2016-08-04 17:33:30 |
Dan Streetman |
attachment removed |
lp1609898.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714179/+files/lp1609898.debdiff |
|
|
| 2016-08-04 17:33:52 |
Dan Streetman |
attachment added |
|
lp1609898-xenial.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714183/+files/lp1609898-xenial.debdiff |
|
| 2016-08-04 17:34:06 |
Dan Streetman |
nominated for series |
|
Ubuntu Yakkety |
|
| 2016-08-04 17:34:26 |
Dan Streetman |
isc-dhcp (Ubuntu): assignee |
|
Dan Streetman (ddstreet) |
|
| 2016-08-04 17:34:33 |
Dan Streetman |
isc-dhcp (Ubuntu): importance |
Undecided |
Medium |
|
| 2016-08-04 17:34:39 |
Dan Streetman |
isc-dhcp (Ubuntu): status |
New |
In Progress |
|
| 2016-08-04 18:45:58 |
Chris J Arges |
bug task added |
|
isc-dhcp (Ubuntu Precise) |
|
| 2016-08-04 18:46:03 |
Chris J Arges |
bug task added |
|
isc-dhcp (Ubuntu Trusty) |
|
| 2016-08-04 18:46:10 |
Chris J Arges |
bug task added |
|
isc-dhcp (Ubuntu Xenial) |
|
| 2016-08-04 18:46:17 |
Chris J Arges |
bug task added |
|
isc-dhcp (Ubuntu Yakkety) |
|
| 2016-08-04 19:12:49 |
Dan Streetman |
attachment added |
|
lp1609898-yakkety.debdiff https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1609898/+attachment/4714232/+files/lp1609898-yakkety.debdiff |
|
| 2016-08-04 20:33:07 |
Ubuntu Foundations Team Bug Bot |
tags |
|
patch |
|
| 2016-08-04 20:33:15 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Ubuntu Sponsors Team |
| 2016-08-06 07:56:41 |
Mathew Hodson |
isc-dhcp (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2016-08-06 07:56:45 |
Mathew Hodson |
isc-dhcp (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2016-08-06 07:56:48 |
Mathew Hodson |
isc-dhcp (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2016-08-08 06:37:46 |
Mathew Hodson |
bug watch added |
|
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009 |
|
| 2016-08-08 06:37:46 |
Mathew Hodson |
bug task added |
|
isc-dhcp (Debian) |
|
| 2016-08-08 06:58:00 |
Bug Watch Updater |
isc-dhcp (Debian): status |
Unknown |
Fix Released |
|
| 2016-08-26 07:02:20 |
Martin Pitt |
isc-dhcp (Ubuntu Yakkety): status |
In Progress |
Fix Committed |
|
| 2016-08-26 07:06:35 |
Martin Pitt |
isc-dhcp (Ubuntu Precise): status |
New |
In Progress |
|
| 2016-08-26 07:06:37 |
Martin Pitt |
isc-dhcp (Ubuntu Trusty): status |
New |
In Progress |
|
| 2016-08-26 07:06:38 |
Martin Pitt |
isc-dhcp (Ubuntu Xenial): status |
New |
In Progress |
|
| 2016-08-26 07:06:55 |
Martin Pitt |
removed subscriber Ubuntu Sponsors Team |
|
|
|
| 2016-09-06 12:58:33 |
Martin Pitt |
isc-dhcp (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2016-09-06 12:58:37 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-09-06 12:58:39 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2016-09-06 12:58:46 |
Martin Pitt |
tags |
patch |
patch verification-needed |
|
| 2016-09-12 15:47:07 |
Dan Streetman |
tags |
patch verification-needed |
patch verification-done-xenial |
|
| 2016-09-12 17:32:50 |
Dan Streetman |
tags |
patch verification-done-xenial |
patch verification-done-xenial verification-done-yakkety |
|
| 2016-09-14 12:14:38 |
Chris J Arges |
isc-dhcp (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2016-09-14 12:14:50 |
Chris J Arges |
tags |
patch verification-done-xenial verification-done-yakkety |
patch verification-done-xenial verification-done-yakkety verification-needed |
|
| 2016-09-14 12:15:38 |
Chris J Arges |
isc-dhcp (Ubuntu Precise): status |
In Progress |
Fix Committed |
|
| 2016-09-15 01:35:08 |
paz |
bug |
|
|
added subscriber paz |
| 2016-09-15 17:08:27 |
Dan Streetman |
tags |
patch verification-done-xenial verification-done-yakkety verification-needed |
patch verification-done-precise verification-done-xenial verification-done-yakkety verification-needed |
|
| 2016-09-15 17:11:53 |
Dan Streetman |
tags |
patch verification-done-precise verification-done-xenial verification-done-yakkety verification-needed |
patch verification-done-precise verification-done-trusty verification-done-xenial verification-done-yakkety |
|
| 2016-09-15 17:47:39 |
Dan Streetman |
bug task added |
|
network-manager (Ubuntu) |
|
| 2016-09-15 17:48:09 |
Dan Streetman |
network-manager (Ubuntu Precise): status |
New |
Invalid |
|
| 2016-09-15 17:49:12 |
Dan Streetman |
attachment added |
|
debdiff to fix network manager test in trusty https://bugs.launchpad.net/ubuntu/precise/+source/network-manager/+bug/1609898/+attachment/4741541/+files/lp1609898-nm-trusty.debdiff |
|
| 2016-09-15 17:49:38 |
Dan Streetman |
attachment added |
|
lp1609898-nm-xenial.debdiff https://bugs.launchpad.net/ubuntu/precise/+source/network-manager/+bug/1609898/+attachment/4741542/+files/lp1609898-nm-xenial.debdiff |
|
| 2016-09-15 17:50:02 |
Dan Streetman |
attachment added |
|
lp1609898-nm-yakkety.debdiff https://bugs.launchpad.net/ubuntu/precise/+source/network-manager/+bug/1609898/+attachment/4741543/+files/lp1609898-nm-yakkety.debdiff |
|
| 2016-09-15 19:02:36 |
Mathew Hodson |
bug |
|
|
added subscriber Mathew Hodson |
| 2016-09-22 01:13:36 |
Dan Streetman |
description |
[Impact]
clients who get an ipv6 address from a dhcpv6 server assume the address has a /64 prefix, but that is not necessarily true, and if the subnet is different than /64 those clients will not be able to reach other addresses in that /64 prefix because the other systems are not on-link. This /64 assumption of dhclient effectively breaks the client networking for certain addresses.
[Test Case]
Set up a server with two interface nics, and one client connected to each of those interfaces. On the server, set up a ipv6 subnet on each interface, with a larger prefix than /64, e.g.:
2001:db8:0:0:1::/96
2001:db8:0:0:2::/96
configure dhcpv6 on the server, to provide ipv6 addresses on each interface. Set the server as the default ipv6 route for the clients.
Allow the clients to get dhcpv6 ipv6 addresses from the server. The clients will each get a ipv6 address with a /64 prefix, due to the bug in dhclient.
Try to ping (or otherwise communicate) between the clients. Since they have /64 prefixes, they think they are on-link with each other, but they are not, so they can't communicate.
After the dhclient bug is fixed, repeat the above setup, and the clients will get /128 prefixes instead, and then will be able to communicate with each other, because they will route the traffic to each other through the server.
[Regression potential]
None. Non-standard (i.e. not /64) subnets served by dhcpv6 currently are broken, this fixes that.
[Other info]
This is fixed in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009 |
[Impact]
clients who get an ipv6 address from a dhcpv6 server assume the address has a /64 prefix, but that is not necessarily true, and if the subnet is different than /64 those clients will not be able to reach other addresses in that /64 prefix because the other systems are not on-link. This /64 assumption of dhclient effectively breaks the client networking for certain addresses.
[Test Case]
Set up a server with two interface nics, and one client connected to each of those interfaces. On the server, set up a ipv6 subnet on each interface, with a larger prefix than /64, e.g.:
2001:db8:0:0:1::/96
2001:db8:0:0:2::/96
configure dhcpv6 on the server, to provide ipv6 addresses on each interface. Set the server as the default ipv6 route for the clients.
Allow the clients to get dhcpv6 ipv6 addresses from the server. The clients will each get a ipv6 address with a /64 prefix, due to the bug in dhclient.
Try to ping (or otherwise communicate) between the clients. Since they have /64 prefixes, they think they are on-link with each other, but they are not, so they can't communicate.
After the dhclient bug is fixed, repeat the above setup, and the clients will get /128 prefixes instead, and then will be able to communicate with each other, because they will route the traffic to each other through the server.
[Regression potential]
Non-standard (i.e. not /64) subnets served by dhcpv6 currently are broken, this fixes that.
However, any ipv6 network configurations that rely on the previous incorrect assumed /64 behavior (as described here: https://tools.ietf.org/html/rfc5942#section-5) in order to allow dhcpv6 clients to communicate with other systems inside the subnet, but do not use RA to also provide clients with the actual prefix len, will break.
To clarify: a server that provides clients with dhcpv6 addresses, but does not also provide the prefix len via RA, will change behavior; previously, all clients on the subnet could talk directly to each other, with this update the clients cannot talk to each other directly; all traffic between clients will be routed through the default gateway.
Further, if the network does not provide a default gateway - for example a local network that is intended only for traffic between local servers - the clients will not be able to talk to each other at all.
Note that such configurations *are* broken configurations, that just happened to work before because of incorrect dhcp client behavior; such configurations must be updated to perform RA to provide the prefix len to clients.
[Other info]
This is fixed in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009 |
|
| 2016-09-22 01:42:24 |
Mathew Hodson |
description |
[Impact]
clients who get an ipv6 address from a dhcpv6 server assume the address has a /64 prefix, but that is not necessarily true, and if the subnet is different than /64 those clients will not be able to reach other addresses in that /64 prefix because the other systems are not on-link. This /64 assumption of dhclient effectively breaks the client networking for certain addresses.
[Test Case]
Set up a server with two interface nics, and one client connected to each of those interfaces. On the server, set up a ipv6 subnet on each interface, with a larger prefix than /64, e.g.:
2001:db8:0:0:1::/96
2001:db8:0:0:2::/96
configure dhcpv6 on the server, to provide ipv6 addresses on each interface. Set the server as the default ipv6 route for the clients.
Allow the clients to get dhcpv6 ipv6 addresses from the server. The clients will each get a ipv6 address with a /64 prefix, due to the bug in dhclient.
Try to ping (or otherwise communicate) between the clients. Since they have /64 prefixes, they think they are on-link with each other, but they are not, so they can't communicate.
After the dhclient bug is fixed, repeat the above setup, and the clients will get /128 prefixes instead, and then will be able to communicate with each other, because they will route the traffic to each other through the server.
[Regression potential]
Non-standard (i.e. not /64) subnets served by dhcpv6 currently are broken, this fixes that.
However, any ipv6 network configurations that rely on the previous incorrect assumed /64 behavior (as described here: https://tools.ietf.org/html/rfc5942#section-5) in order to allow dhcpv6 clients to communicate with other systems inside the subnet, but do not use RA to also provide clients with the actual prefix len, will break.
To clarify: a server that provides clients with dhcpv6 addresses, but does not also provide the prefix len via RA, will change behavior; previously, all clients on the subnet could talk directly to each other, with this update the clients cannot talk to each other directly; all traffic between clients will be routed through the default gateway.
Further, if the network does not provide a default gateway - for example a local network that is intended only for traffic between local servers - the clients will not be able to talk to each other at all.
Note that such configurations *are* broken configurations, that just happened to work before because of incorrect dhcp client behavior; such configurations must be updated to perform RA to provide the prefix len to clients.
[Other info]
This is fixed in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009 |
[Impact]
clients who get an ipv6 address from a dhcpv6 server assume the address has a /64 prefix, but that is not necessarily true, and if the subnet is different than /64 those clients will not be able to reach other addresses in that /64 prefix because the other systems are not on-link. This /64 assumption of dhclient effectively breaks the client networking for certain addresses.
[Test Case]
Set up a server with two interface nics, and one client connected to each of those interfaces. On the server, set up a ipv6 subnet on each interface, with a larger prefix than /64, e.g.:
2001:db8:0:0:1::/96
2001:db8:0:0:2::/96
configure dhcpv6 on the server, to provide ipv6 addresses on each interface. Set the server as the default ipv6 route for the clients.
Allow the clients to get dhcpv6 ipv6 addresses from the server. The clients will each get a ipv6 address with a /64 prefix, due to the bug in dhclient.
Try to ping (or otherwise communicate) between the clients. Since they have /64 prefixes, they think they are on-link with each other, but they are not, so they can't communicate.
After the dhclient bug is fixed, repeat the above setup, and the clients will get /128 prefixes instead, and then will be able to communicate with each other, because they will route the traffic to each other through the server.
[Regression Potential]
Non-standard (i.e. not /64) subnets served by dhcpv6 currently are broken, this fixes that.
However, any ipv6 network configurations that rely on the previous incorrect assumed /64 behavior (as described here: https://tools.ietf.org/html/rfc5942#section-5) in order to allow dhcpv6 clients to communicate with other systems inside the subnet, but do not use RA to also provide clients with the actual prefix len, will break.
To clarify: a server that provides clients with dhcpv6 addresses, but does not also provide the prefix len via RA, will change behavior; previously, all clients on the subnet could talk directly to each other, with this update the clients cannot talk to each other directly; all traffic between clients will be routed through the default gateway.
Further, if the network does not provide a default gateway - for example a local network that is intended only for traffic between local servers - the clients will not be able to talk to each other at all.
Note that such configurations *are* broken configurations, that just happened to work before because of incorrect dhcp client behavior; such configurations must be updated to perform RA to provide the prefix len to clients.
[Other Info]
This is fixed in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009 |
|
| 2016-09-22 11:31:32 |
Martin Pitt |
network-manager (Ubuntu Yakkety): importance |
Undecided |
Medium |
|
| 2016-09-22 11:31:32 |
Martin Pitt |
network-manager (Ubuntu Yakkety): status |
New |
Fix Committed |
|
| 2016-09-22 11:31:32 |
Martin Pitt |
network-manager (Ubuntu Yakkety): assignee |
|
Martin Pitt (pitti) |
|
| 2016-09-22 11:31:50 |
Martin Pitt |
network-manager (Ubuntu Xenial): status |
New |
Triaged |
|
| 2016-09-22 11:32:09 |
Martin Pitt |
network-manager (Ubuntu Trusty): status |
New |
Triaged |
|
| 2016-09-23 14:19:42 |
Dan Streetman |
description |
[Impact]
clients who get an ipv6 address from a dhcpv6 server assume the address has a /64 prefix, but that is not necessarily true, and if the subnet is different than /64 those clients will not be able to reach other addresses in that /64 prefix because the other systems are not on-link. This /64 assumption of dhclient effectively breaks the client networking for certain addresses.
[Test Case]
Set up a server with two interface nics, and one client connected to each of those interfaces. On the server, set up a ipv6 subnet on each interface, with a larger prefix than /64, e.g.:
2001:db8:0:0:1::/96
2001:db8:0:0:2::/96
configure dhcpv6 on the server, to provide ipv6 addresses on each interface. Set the server as the default ipv6 route for the clients.
Allow the clients to get dhcpv6 ipv6 addresses from the server. The clients will each get a ipv6 address with a /64 prefix, due to the bug in dhclient.
Try to ping (or otherwise communicate) between the clients. Since they have /64 prefixes, they think they are on-link with each other, but they are not, so they can't communicate.
After the dhclient bug is fixed, repeat the above setup, and the clients will get /128 prefixes instead, and then will be able to communicate with each other, because they will route the traffic to each other through the server.
[Regression Potential]
Non-standard (i.e. not /64) subnets served by dhcpv6 currently are broken, this fixes that.
However, any ipv6 network configurations that rely on the previous incorrect assumed /64 behavior (as described here: https://tools.ietf.org/html/rfc5942#section-5) in order to allow dhcpv6 clients to communicate with other systems inside the subnet, but do not use RA to also provide clients with the actual prefix len, will break.
To clarify: a server that provides clients with dhcpv6 addresses, but does not also provide the prefix len via RA, will change behavior; previously, all clients on the subnet could talk directly to each other, with this update the clients cannot talk to each other directly; all traffic between clients will be routed through the default gateway.
Further, if the network does not provide a default gateway - for example a local network that is intended only for traffic between local servers - the clients will not be able to talk to each other at all.
Note that such configurations *are* broken configurations, that just happened to work before because of incorrect dhcp client behavior; such configurations must be updated to perform RA to provide the prefix len to clients.
[Other Info]
This is fixed in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009 |
[Impact]
clients who get an ipv6 address from a dhcpv6 server assume the address has a /64 prefix, but that is not necessarily true, and if the subnet is different than /64 those clients will not be able to reach other addresses in that /64 prefix because the other systems are not on-link. This /64 assumption of dhclient effectively breaks the client networking for certain addresses.
[Test Case]
Set up a server with two interface nics, and one client connected to each of those interfaces. On the server, set up a ipv6 subnet on each interface, with a larger prefix than /64, e.g.:
2001:db8:0:0:1::/96
2001:db8:0:0:2::/96
configure dhcpv6 on the server, to provide ipv6 addresses on each interface. Set the server as the default ipv6 route for the clients.
Allow the clients to get dhcpv6 ipv6 addresses from the server. The clients will each get a ipv6 address with a /64 prefix, due to the bug in dhclient.
Try to ping (or otherwise communicate) between the clients. Since they have /64 prefixes, they think they are on-link with each other, but they are not, so they can't communicate.
After the dhclient bug is fixed, repeat the above setup, and the clients will get /128 prefixes instead, and then will be able to communicate with each other, because they will route the traffic to each other through the server.
[Regression Potential]
Non-standard (i.e. not /64) subnets served by dhcpv6 currently are broken, this fixes that.
However, any ipv6 network configurations that rely on the previous incorrect assumed /64 behavior (as described here: https://tools.ietf.org/html/rfc5942#section-5) in order to allow dhcpv6 clients to communicate with other systems inside the subnet, but do not use RA to also provide clients with the actual prefix len, will break.
To clarify: a server that provides clients with dhcpv6 addresses, but does not also provide the prefix len via RA, will change behavior; previously, all clients on the subnet could talk directly to each other, with this update the clients cannot talk to each other directly; all traffic between clients will be routed through the default gateway.
Further, if the network does not provide a default gateway - for example a local network that is intended only for traffic between local servers - the clients will not be able to talk to each other at all.
Note that such configurations *are* broken configurations, that just happened to work before because of incorrect dhcp client behavior; such configurations must be updated to perform RA to provide the prefix len to clients.
See comment 30 for details on how to configure radvd to restore network functionality.
[Other Info]
This is fixed in debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684009 |
|
| 2016-09-26 20:41:23 |
Martin Pitt |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2016-09-26 20:41:21 |
Launchpad Janitor |
isc-dhcp (Ubuntu Precise): status |
Fix Committed |
Fix Released |
|
| 2016-09-26 20:42:12 |
Launchpad Janitor |
isc-dhcp (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2016-09-26 20:42:28 |
Launchpad Janitor |
isc-dhcp (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-09-27 14:29:18 |
Martin Pitt |
network-manager (Ubuntu Xenial): status |
Triaged |
Fix Committed |
|
| 2016-09-27 14:58:36 |
Andy Whitcroft |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2016-09-27 14:58:43 |
Andy Whitcroft |
tags |
patch verification-done-precise verification-done-trusty verification-done-xenial verification-done-yakkety |
patch verification-done-precise verification-done-trusty verification-done-xenial verification-done-yakkety verification-needed |
|
| 2016-09-27 19:33:52 |
Martin Pitt |
tags |
patch verification-done-precise verification-done-trusty verification-done-xenial verification-done-yakkety verification-needed |
patch verification-done |
|
| 2016-09-27 20:34:28 |
Mathew Hodson |
network-manager (Ubuntu Xenial): importance |
Undecided |
Medium |
|
| 2016-09-27 20:34:40 |
Mathew Hodson |
network-manager (Ubuntu Trusty): importance |
Undecided |
Medium |
|
| 2016-09-28 09:17:08 |
Launchpad Janitor |
network-manager (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2016-09-28 09:18:36 |
Launchpad Janitor |
isc-dhcp (Ubuntu Yakkety): status |
Fix Committed |
Fix Released |
|
| 2016-10-12 08:23:18 |
Launchpad Janitor |
network-manager (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
| 2016-11-29 23:27:36 |
Mathew Hodson |
removed subscriber Mathew Hodson |
|
|
|
| 2019-05-25 14:32:35 |
Dan Streetman |
network-manager (Ubuntu Trusty): status |
Triaged |
Won't Fix |
|
| 2019-05-25 14:32:47 |
Dan Streetman |
removed subscriber Dan Streetman |
|
|
|
