Hi James, My thinking evolved from DNS search list option defined in RFC3646, hence using DHCPv6 seemed like a logical choice.
Additionally collecting information required for multi-homing configuration into one place (DHCPv6) seemed useful: this option, DHCPv6 Route Option (draft-ietf-mif-dhcpv6-route-option), and Distributing Address Selection Policy using DHCPv6 (draft-ietf-6man-addr-select-opt). I.e. single point of control but different point than what you propose below. DHCPv6 can also support node specific configurations. Addition of information refreshing considerations is a good proposal. The RFC4242, "Information Refresh Time Option", can be utilized for this purpose. Well include considerations of this. About packet integrity protection.. I have thought the same level of integrity protection we have for other DHCPv6 configuration options would suffice. About IPv4 and IPv6. Generally multi-homing for IPv4 is a lost cause due serious problems caused by overlapping private addresses and subnets. I will consider IPv4 multi-homing only if really really necessary. (This reminds me of v6ops discussion about whether IPv4 should be declared historic and hence no new work (save security fixes) would need to be done for IPv4 in IETF:) Best regards, Teemu > -----Original Message----- > From: ext James Carlson [mailto:[email protected]] > Sent: 11. tammikuuta 2011 19:12 > To: Savolainen Teemu (Nokia-MS/Tampere); [email protected] > Cc: [email protected] > Subject: draft-savolainen-mif-dns-server-selection-06.txt > > 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 > <[email protected]> _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
