I would like to get more feedback from DHCPv6 users. Preferably, to prioritize the list below. What would be the number one priority item from this list that DHCPv6 users would like to address?
Thanks,
Dusan
-----Original Message-----
From: dhcwg [mailto:
[hidden email]] On Behalf Of Simon Hobson
Sent: Monday, February 13, 2017 9:57 AM
To: dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition
"Mudric, Dusan (Dusan)" <
[hidden email]> wrote:
> PROBLEM STATEMENTS:
> - A network operator can set client IPv6 addresses on DHCPv6 server.
That is the primary function of the DHCP server ! I don't see that as a problem.
> An address can be invalid or make a client unreachable.
There are a lot of other ways to bo**ox up a network !
Such configurations may be deliberate. Until recently I did in fact run a network with unroutable (as in valid IP, but no router for that subnet) addresses because there was a policy decision that this particular network would be isolated - it was a backend network to carry traffic independently of the traffic on the public facing front end network.
> - A network operator can change an address prefix on a router. A client address can become unreachable
Ditto.
This is simply failing to co-ordinate network changes. Before removing/changing the prefix, the DHCP admin should have removed the pool IFF it is desired that the addresses be usable for external connectivity. As previously mentioned, this may be deliberate on the part of the Admin.
> - A default router offering a prefix to a client can become unreachable.
"Sh*t happens". Not only that, but what happens if the server hands out a load of IPv6 addresses which are all valid AT THE TIME OF ALLOCATION ? Even if your proposal were implemented, these addresses would be accepted and configured because they would be valid AT THE TIME OF ALLOCATION. The DHCP server and client cannot do anything about it if, say, 5 seconds into a 60 day lease, a router stops advertising a prefix appropriate to that address.
It would be for the OS to detect that situation, and simply stop using that address for outbound connections. IMO it would be inappropriate for all the clients to somehow tell the server that all these addresses are bad - only to have 20,000 clients all contact the server again a few minutes later when the router comes back up and the prefix becomes valid again. That would be designing in network instability.
> A client address can become unreachable on a local link
?
> - A client does not release unused addresses
So ? There's 2^64 addresses in a minimal IPv6 prefix. How many billion addresses do you intend using for each client ? Even if your 20,000 clients all took and held onto 1000 addresses each, that's still a tiny tiny fraction of the available addresses.
> - A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems
HOW ?
You will need to define the algorithm for validating addresses. So far you've only come up with "isn't on any prefix advertised by a router" (as above, not a valid test) and "in a deprecated prefix" (as mentioned in an earlier message, not a valid test).
You will also need to define a mechanism whereby all clients can have the algorithm updated as policies change - eg prefixes get deprecated (as previously discussed), new prefixes come into use (eg I assume you would expect currently unused prefixes to be rejected, but they could come into use at any time when it's considered that they are needed).
You will also need to define a mechanism for the local admins to over-ride the stock algorithm - eg where the admins have made a policy decision to run isolated networks. This introduces a catch-22 situation where new devices might not be configurable (they won't attach to the network) until they have been configured (policy edited to allow them to connect).
This is critical to your proposal - until you can come up with an easily defined, and robust, algorithm then your proposal CANNOT work. Worse, it may cause far more problems than it is supposed to solve.
> - A client returns unused addresses
> - DHCPv6 server:
> -- logs error messages (invalid & unreachable addresses with device IDs)
> -- does not assign the invalid addresses
> -- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again
Define "valid" and "reachable" here ?
The implication from this and your earlier emails is that you define "reachable" as "has an IP which is routable to/from 'the internet'". See my comment above about running isolated networks, that backend isolated network runs a DHCP service - so the addresses on it are "reachable" in terms of "the DHCP server can reach them", but they aren't globally routable (they are actually RFC1918 IPv4 addresses, but the argument stands).
With a previous hat on, I had 2 Class C public IPv4 allocations which weren't globally routable.
There is also the issue that the server (in the general case) CANNOT determine the reachability/routability of any prefix. There are plenty of network topologies where the server may lose connectivity to "something" while clients don't, or vice-versa, while connectivity between server and client network is still working. Similarly, there are topologies while server-client comms could be lost, while both still have connectivity to "something". This is the reason that, out of the box, DHCP4 servers in failover do NOT automatically go into partner-down state when they lose connectivity between them.
> - An operator
> -- checks if there are unreachable devices and the reason codes
An alternative: The site/organisation admins take care to co-ordinate changes, and test changes in configuration. They should employ monitoring to detect issues, and respond appropriately to helpdesk tickets.
Configuration management (and especially automation) will detect many of the issues you've raised.
_______________________________________________
dhcwg mailing list
[hidden email]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=-9s7e0Ks0EQLldj5oI4E9zLJKH-0ehGNzPg6r665zKo&s=yZV16lh2Yih0GhvVieDz2J5SHShPy-iKWBYCkGKJkSo&e=
-----Original Message-----
From: dhcwg [mailto:
[hidden email]] On Behalf Of Mudric, Dusan (Dusan)
Sent: Monday, February 13, 2017 9:02 AM
To: dhcp-users; dhcwg
Subject: Re: [dhcwg] RFC3315 DECLINE definition
Thanks to DHCWG group for their comments. I believe the proposals would benefit DHCv6 users.
For the record:
PROBLEM STATEMENTS:
- A network operator can set client IPv6 addresses on DHCPv6 server. An address can be invalid or make a client unreachable.
- A network operator can change an address prefix on a router. A client address can become unreachable
- A default router offering a prefix to a client can become unreachable. A client address can become unreachable on a local link
- A client does not release unused addresses
PROPOSED FAILURE INDICATIONS
- A client validates the addresses and the address prefixes and notifies DHCPv6 server about the problems
- A client returns unused addresses
- DHCPv6 server:
-- logs error messages (invalid & unreachable addresses with device IDs)
-- does not assign the invalid addresses
-- periodically checks for the reachability of unreachable addresses and, when they become reachable, assigns them again
- An operator
-- checks if there are unreachable devices and the reason codes _______________________________________________
dhcwg mailing list
[hidden email]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=DQICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=Qxk02ZIjaVguViwH6GFfRlZ1P5VOsYQOjA3jNkynsoA&s=2J3Xq9IQVsoMl7JTQP52olq6E_tc1b6kLGRuJ0RnkWE&e=_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Locked
