DHCPv6 *still* broken for F17 alpha

[Glen Turner]

On 2012-03-15 Dan Williams wrote:
> The only effect this checking will have is to change NetworkManager's
> state from CONNECTED_GLOBAL to CONNECTED_SITE or CONNECTED_LOCAL.  It
> doesn't do anything odd like disconnect and retry some other
connection,
> which wouldn't make much sense.  It just changes some state which apps
> can use to figure out whether they'd connect to say your IRC server or
> your email or whatever automatically.

Hi Dan,

I suggest that is something the application should determine, not
NetworkManager.

Take the case where a ISP loses international connectivity, then a
NetworkManager-informed application won't connect to the in-country
ISP's IRC/e-mail/... server even though those servers are available.
Thus connectivity detection worsens a partial loss of connectivity into
a full loss of connectivity.

The app has to be able to handle no connectivity anyway: just because
Network Manager can HTTP GET the URI doesn't mean that IRC works. For
example, a corporate firewall could allow HTTP but block IRC.

Both the end-to-end argument and occam's razor argue for the application
gracefully handling no connectivity.

The current situation is that many apps don't handle a lack of
connectivity with grace. But I suggest that this isn't NetworkManager's
problem to solve.

Even the current situation isn't great. NetworkManager shouldn't be
telling applications that the network is available. That DBUS
message should be triggered by the insertion into the main forwarding
table of a default route. Then any source of global connectivity will
set the app connecting (NM, NM work alikes, "ip route add", ospfd,
tunnels, etc).

Best wishes, Glen

PS: I really don't understand the operation of dnssec-triggerd. The
paths for HTTP and DNS traffic through an enterprise network can be very
different so testing one protocol doesn't say a huge amount about the
availability of the other protocol.  But then I don't even understand
the desirability of that program: allowing an external event (eg an
access list on a router or a DoS attack) to trigger a reconfiguration
from a DNSSEC-validating to a non-validating configuration seems more of
a security bug than a feature. But I'm likely missing something here.