I read this draft with some interest, as I've run into this sort of
problem many times myself.
I'm curious, though, about the architectural implications of the
described design. In particular, the use of DHCPv6 to convey
suffix/prefix information means that the DHCP server needs to be updated
as various suffixes/prefixes change within a network, and clients need
(somehow) to know to refresh that information as it changes.
For example, suppose my DNS is configured with a set of ip6.arpa
mappings representing my current networks. I configure my DHCPv6 server
to list these suffixes as part of OPTION_DNS_SERVER_SELECT, so that
clients will know that my DNS server contains this information.
Now I deploy a few new IPv6 networks within my organization. I have to
update DNS, of course, with the new ip6.arpa entries. But because I'm
using the feature described in this draft, I now have to update DHCPv6
as well, and I have to make sure that the clients all "refresh" their
DHCP-derived information. If I don't, then clients will suffer with
incorrect filters (and thus failed look-ups) until they restart.
So, my question is this: did you consider placing the required
suffix/prefix information into DNS itself? As a simple example -- not
intended to be a complete design -- you could add a new TXT entry to DNS
that contains the same data as the "DNS suffixes and prefixes"
information in this draft. Clients could then get DNS server addresses
through the existing DHCPv6 mechanisms, and then query the server to get
this new TXT record. If present, then it gives the same information as
in this draft, *plus* it includes the normal DNS lifetime data and
caching behavior. If absent, then the client just assumes that the
server contains all data, just as specified in the existing draft, and
just as it should today.
If you did it based on DNS instead of DHCPv6, then you'd have the
following benefits:
1. The DNS server's existing caching behavior would cover both
changes to the suffix/prefix list and to the actual data served,
so the administrator would have a single point of control.
2. Clients would not be forced to refresh DHCPv6 data when the
contents of the DNS server (the list of suffixes/prefixes
served) changes.
3. If DNSSEC is in use, it would protect the suffix/prefix list;
something that's missing from the DHCPv6 approach.
4. The same approach would work seamlessly for IPv4 and IPv6.
I can see no obvious negative aspects of such a design, though I
certainly admit that I could be missing key issues.
Did you consider this sort of design? If so, why was a DHCPv6 extension
chosen instead?
--
James Carlson 42.703N 71.076W <carls...@workingcode.com>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
